...
Draft messages for the different announcements are prepared on the following page: Release Management announcements
Planning and progress tracking for a meta-release
...
This results in the new meta-release plan to be used for tracking the meta-release.
Milestone activities
Before M0
Request the TSC to declare the meta-release kick-off.
Provide the release-candidate of the Release Management assets with any updates based on feedback received.
M0
Announce the meta-release kick-off on the CAMARA mailing list (all@lists.camaraproject.org). This announcement indicates:
the Commonalities and ICM teams to prepare for M1 the scope definition of what they plan to put in the meta-release
all API Sub Projects to create the API release tracker for their next planned API version(s) as described here: API release trackers.
the Outreach Committee to start preparation of marketing activities based on information in the meta-release plan
Once available, check the final alpha releases PR release PRs of Commonalities & ICM and their release asset availability. If OK, submit to TSC for approval.
Provide the public release of the Release Management assets for use by the API Sub Projects.
After TSC approval, announce M1 on the release management and maintainers mailing lists.
M1
Check for Commonalities and ICM that all release assets are available in their final release candidate PRs.
If OK, request TSC to approve creation of the final release candidate of Commonalities and ICM.
After TSC approval, and update of the meta-release plan with the final release candidate tags of Commonalities and ICM, announce M2 milestone.
M2
From M1, for all APIs, once available, check the first API release PR for the release candidate PR API version, and, if OK, approve PR.
Announce M3 milestone once all approved API release candidates have update their API release tracker.
M3
For all APIs, once available, check the release PR for the final API release candidate PR API version and, if OK, approve PR. Approval can start as soon as an API Sub Project indicates "M4: ready for RM" on the API release tracker in the comments field. It is not necessary to wait for the actual M4 date if an API release is ready before.
For all APIs, once available, check API public release PR, and, if OK, ask for formal TSC approval.
Announce M4 milestone when all API public releases are approved by TSC.
M4
Check that all API release trackers are updated with their public release tag for the meta-release.
Propose meta-release content to TSC.
After TSC approval, publish the meta-release.
Announce the M5 meta-release on all@lists.camaraproject.org
M5
Review the release process with all teams and identify areas for improvement for the next meta release with all teams. A meta-release feedback page is available to all to add comments, feedback and suggestions for improvement. I
Propose improvements for TSC approval to TSC to be implemented for the next meat-release.
After TSC approval, announce M6 milestone
M6
...
Milestone | Before milestone | After At milestone |
|---|---|---|
M0 | kickmeta-off release preparation | kick-off doneannouncement |
M1 (Commonalities & ICM) | alpha release PR | alpha for M2release |
M2 (Commonalities & ICM) | public release candidate PR | public release candidate for M4 |
M3 (APIs) | API first release candidate PRAPI | first release candidate for M4 |
M4 API final release candidate PR API (APIs) | public release PR | API final release candidate API public release for M5 |
M5 | meta-release preparationcreation | meta-release publishedannouncement |
M6 | retrospective preparation | retrospective doneimplementation |
Commonalities and ICM
The Commonalities and ICM teams shall respectively update and maintain their information directly on the active meta-release plan accessible here: CAMARA meta-releases (select the active meta-release from the list).
...
Field | Field explanation | When to update |
|---|---|---|
Target version | the public release version targeted for the meta-release | at M0 or when the target scope issue is created |
Target scope | link to GitHub issue defining the release scope | when the issue is created |
M1 / date | date of pre-release or actual final alpha release milestone date | when each alpha release is created |
M2 / date | date of pre-release or actual final release candidate milestone date | when each release candidate is created |
(Pre)release tag | link to latest pre-release (alpha or release candidate) | when a new pre-release is created |
M5 / date | actual final public release milestone date | when the public release is created |
Public release tag | link to final public release tag | when the public release is created |
Patch date | publication date of patch release (if any) | if a patch to the public release is created |
Milestone activities
The activities of the Commonalities and ICM teams during the release process are the following:
before M0:
Starting from the M2 of the previous meta-release, prepare the scope definition for the upcoming meta-release.
Start implementing the scope through one or more alpha releases.
M0
As soon as possible after M0, fix the scope definition for the meta-release:
Record scope in a dedicated GitHub issue, e.g. called "Fall24Spring25: Commonalities / ICM scope".
Submit scope issue for TSC review
Develop final Commonalities & ICM scope through one or more alpha releases
Update data in the meta-release plan with each alpha release
For M1:
Create the final alpha release PRs PR and submit to Release Management
After TSC approval, create approved final alpha release for of Commonalities & ICM for use by API Sub Projects
Update the meta-release plan with the alpha release tag
M1
Fix bugs raised by users through one or more release candidates
Update data in the meta-release plan with each release candidate
For M2:
Create final release candidate PR and submit to Release Management for checking
After TSC approval, create approved final release candidate for Commonalities & ICM
Update the meta-release plan with the final release candidate release tag. The final release candidate shall be used by the API Sub Projects to work with for their API release candidate development.
M2
Start the scope definition and alpha release for the next meta-release.
M3 and / M4 - 2 weeks
During Following API development (M3) and testing (M4), changes to the final Commonalities or ICM release candidates may be requested, leading to new release candidates to be reflected on the meta-release page.
The final public release PR releases of the Commonalities and ICM will only shall be created available latest 2 weeks before the M4 date. Once committedreleased, these will also be used for M5 for inclusion in the meta-release.
For this:
Fix bugs/requested changes raised by API testers through one or more release candidates
Create the public release PR for Commonalities & ICM
After Release Management check and TSC approval of the public release PR
Create the public release
Update the meta-release page with public release tag
M4
M5
Provide feedback on meta-release
M6
After public release, create maintenance release when necessary.
Version and release numbering
Version numbering
For Commonalities and ICM, the version and release for a given meta-release is are documented on the meta-release plan.
The version numbering scheme follows Semantic Versioning 2.0.0.
Release numbering
A Commonalities or ICM release is tagged with a GitHub release tag named as follows:
it is numbered with the version number: x.y.z
is prefixed with "r" in the release tag: rx.y.z
for alpha releases or release candidates it is post-fixed with the version extensions: rx.y.z-alpha.m or rx.y.z-rc.n
for public releases, no version extension is allowed
The following table provides the overview of the release versioning and numbering scheme through the release process.
...
Release type
...
Version number
...
Release number (tag)
...
Milestone
...
NOTE: Version and release numbering follow separate schemes. A given release concerns a specific version of the released artifacts.
Version numbering
For Commonalities and ICM, their version is documented in a dedicated file “VERSION.yaml” in the home folder of the repository. The syntax contains “version: <version>” where version shall follow the same rules as the below referenced API versioning scheme, e;g. for alpha, release-candidate and public versions.
The version numbering follows the same scheme as for APIs as described here: API versioning
Release numbering
The release numbering follows the same scheme as for API releases as described in the section on API release numbering here: API Release Process .
The following table illustrates the use of release and version numbering across the Commonalities and ICM release process.
release type | version | release number (tag) | release package label | Milestone |
|---|---|---|---|---|
N/A | wip | N/A | N/A | M/A |
pre-release | x.y.z-alpha.1. |
.n | rm.1 ... rm.n | "pre-release" | M1 (internal pre-release) |
pre-release |
x.y.z-rc. |
1. |
.m | rm.n+1 ... rm.n+k | "pre-release" | M2 (internal pre-release) |
release | x.y.z |
rm.p (p=n+k+1) | "latest" | M4-2 weeks (public) | ||
maintenance release | x.y.z+1..k | rm.p+1 ... rm.p+q | "latest" | After M5 (public) |
Additional versioning of artifacts
Some artifacts inside Commonalities or ICM that may have their own version. For changes of such artifacts, the following versioning guidelines are provided:
If a versioned artifact change impacts the APIs, then the artifact version and the repository version in the VERSION.yaml file should be changed accordingly (MAJOR, MINOR, PATCH), and a new release shall be created.
If a versioned artifact change impacts does not impact the APIs, then the artifact changes can be done outside a release with their version being updated inline with semver guidelines. The changes shall be included in the next repository release, but the advantage is that the latest updates are available in main, and can be referenced with their version.
An example of the latter could be the update of a template that has its own version that does not impact APIs.
Note: these guidelines are provided, but it is not clear if such separate versioning is actually needed.
API Sub Projects
Release tracking
...