...
All CAMARA teams play their part in the release process. This section describes the action of each team.
Details on releasing API versioning and the link with the release management process is related API versioning are described here: API Release Process.
...
- the Commonalities and ICM teams shall update the the applicable meta-release page with the information scope definition of what they plan to contribute to put in the meta-release, and with the status updates during the meta-release cycle.
- all API Sub-project teams shall create their release tracker page(s) for the API version(s) they plan to contribute to the meta-release.
An The status of the ongoing meta-release status is discussed in the Release Management working group meetings.
...
- the Commonalities and ICM data is updated directly on the meta-release page by the respective teams.
- the API data is managed by the API Sub-project teams on their API release tracker page(s) and pulled into the meta-release page automatically.
Release milestone status
...
- Whenever a new pre-release is made available, the (Pre-)Release release tag column shall be updated with the latest pre-release tag link for the API Commonalities and ICM version respectively.
- The actual milestone dates shall be put in the table when the milestone is achieved.
- The link to the release package, when available, shall be added at each pre-release change, and at M2.
- Once TSC approval is given at M2, the target public-release version shall be created for M5 and the meta-release page updated with the final public-release. The API Sub-projects shall work with the pre-release provided at M2.
API Sub-projects (M0, M3, M4)
API Sub-project teams shall create and update their the API release tracker for the API each of their API(s) as follows:
- With the each prealpha or release-release candidate API version, the API pre-release version and release tag fields shall be updated, and minimally at M3 and M4.
- The actual milestone dates shall be put in the table release tracker when the milestone is passed.The link to the release package, if available, shall be added at each pre-release change, and minimally at M3 and M4.
- When M5 is passed, the link to the public-release API package shall be added.
For API Sub-projects that contain multiple APIs,
- All APIs of the release shall have the same API version.
- If not, a separate API Sub-project shall be created for the API with a different version and it shall be release separately.
API version tag
the main branch always contains the latest API version. It is meant for development.
API pre-releases can be created through initial, alpha or release-candidate API version tags and API version release packages. These pre-releases become more stable with increasing API versions.
- after a pre-release is created, intermediate PRs shall set the API version to just "wip" to indicate its instability until a next pre-release is created.
API version release package
Release packages shall be creates using the GitHub release process.
Each release package shall include the release notes using the provided template.
Each release package has a tag: pre-release or latest.
Meta-release roadmap
Meta-release planning
The process to manage a meta-release roadmaps be found here: Release roadmaps can be found here: Meta-Release Planning