Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

CAMARA meta-releases are scheduled twice per year at approximately 6 month intervals (March and September). Meta-releases are named after major world cities in alphabetical order.

Process

...

Release

...

contacts 

Meta-releases are administered and tracked by

...

The teams can put their release contact names on the Release Contacts (Maintainers) page.

Team release contacts need to subscribe to the release management mailing list.

Process

Details on API versioning and the link with the release management is described here: Release management & versioning - proposal

Meta-release (M0, M5, M6)

A Meta-release has 6 milestones, M0 through M6 described above. For the milestone dates per meta-release, please see the CAMARA Meta-release Roadmap.

The Release Management team has the following activities for each meta-release:

  • Create the meta-release page under CAMARA Meta-releases
  • Inform the teams all team's release contacts through the release management mailing list that they need to provide input to the meta-release page.
  • Declare the kick-off of the meta release.
  • Prepare starting at M4 and publish Publish the meta-release at M5.
  • Conduct a meta-release retrospective as input to the next meta release

At M0 preparation, the below teams shall update the meta-release page with the information of what they plan to contribute to the meta-release, and with the status updates during the meta-release cycle.

Release milestone status

...

The ongoing meta-release status is discussed in the Release Management working group meetings and recorded on the the meta-release page.

The milestone status information is values are defined as follows:

  • M0: meta-release preparation, kick-off
  • M1: scoped, work-in-progress
  • M2: release-candidate, released
  • M3: scoped, work-in-progress
  • M4: release-candidate, released
  • M5: meta-release finalization, published
  • M6: under retro, done

...

  • A folder per API shall be created for its development.
  • The meta-release page shall list the individual APIs in the table with the API version considered in the meta-release.
  • The API version used in the API release asset naming is TBC.for pre- and public releases include the apiname. However, the API OAS definition file only has the semver API version. 

Release branches

  • the main branch always contains the latest API version. It is meant for development.   

  • API versions can be frozen in a work-in-progress pre-release branch or in a release-candidate pre-release branch. These pre-releases become more stable with increasing pre-release numbers.

  • Each pre-release branch has a pre-release tag. 
    • Considering an API Family with
    more
    • multiple APIs inside,
    a Release Tag and a new Release Branch is done when all the APIs are completed
    • the release assets are created separately for each API.

Release packages

Release packages can be creates using the GitHub release process. 

...