Who should be responsible for releasing and updating application descriptors in GitHub repos?

The teams who are responsible for the modules which comprise the application.

e.g. app-acquisitions? Thunderjet is responsible since they are responsible for the acquisition modules

In some cases it may be a shared responsibility between 2 or more teams.

These responsibilities should be captured somewhere, e.g. FOLIO Module/JIRA project-Team-PO-Dev Lead responsibility matrix

Eureka is responsible for the “mega” applications until they’re split up. (app-platform-minimal, app-platform-complete, app-edge-complete)

When should application descriptors be updated? Released?

When a team makes a module release, it should also update the module’s application descriptor and make a release of the application as well.

In the future, some of this may be handled by automation, e.g. renovate bot, etc. This automation does not yet exist, but options/approaches are being investigated. This is currently blocked by some development work (See MGRAPPS-49)

Next Steps:

• FSE/Kitfox to provide details of how this might work.

What is the versioning scheme/approach for applications?

We’d like to follow semver here.

Scenarios:

• Updating a patch version of a module → patch version change at the application level

• Major interface change in one of the application’s modules → major version change at the application level

• Minor interface change in one of the application’s modules → minor version change at the application level

• Adding/removing a module from the application → major version change at the application level

Discussion:

• Do we want to create tags/releases in applications which indicate flower releases?

• What about candidate releases for a given flower release, e.g. during bugfest?

Next steps:

• Generate examples so we can compare approaches and make an informed decision

Who is responsible for making changes to application composition, e.g. splitting applications, moving modules from one application to another?

Splitting applications:

The team or teams responsible for application should coordinate the work with guidance from Eureka team and SAs working with the responsible teams.

Moving modules from one application to another:

The team or teams responsible for applications involved should coordinate the work with guidance from Eureka team and SAs working with the responsible teams.

Application composition should not change in CSP releases.

Combining applications:

The team or teams responsible for the applications being combined should coordinate the work with guidance from Eureka team and SAs working with the responsible teams.

Application composition should not change in CSP releases.

Brand new module (leading to brand new applications or added to an existing application):

The team responsible for the module is also responsible for creating a new application

Discussion:

• Is there any oversight? Approval process?

  • Will likely involved the Technical Council. They’re aware of this, but have not had in-depth discussions about it yet. Maybe the TCR process will be extended to also cover which application the module being evaluated should belong to.

Next Steps:

• Craig will make sure the TC discusses this, and will update this section with links/details once available.

Should we revisit the semver ranges / patterns used for specifying application dependencies

• WRT '*', e.g. 1.1.*

  • this will NOT match snapshot versions. Maybe this isn’t ideal.

• WRT '^', e.g. ^1.1.0

  • will match at least 1.1.0, up to the next major version (2.0.0)

  • this may be the most applicable for use in application dependencies, and is what we’re already using.

• WRT '~', e.g. ~1.1.0

  • will match at least 1.1.0, up to the next minor version (1.2.0)

Is renaming of applications supported?

Not formally. Essentially this is creating a new application, and versioning should start at 1.0.0. The old application should be archived/deprecated (process for this is TBD).