Meta-release Process
This section explains the processes for meta-release planning, milestone scheduling and progress reporting on a meta-release.
- 1 Meta-release introduction
- 2 Meta-release plan
- 3 Meta-release milestones
- 4 Meta-release schedule
- 5 Release contacts
- 6 Planning and progress tracking for a meta-release
- 6.1 Release Management
- 6.1.1 Meta-release tracking
- 6.1.2 Milestone activities
- 6.1.3 Milestone status
- 6.2 Commonalities and ICM
- 6.2.1 Release tracking
- 6.2.2 Milestone activities
- 6.2.3 Version and release numbering
- 6.3 API Sub Projects
- 6.3.1 Release tracking
- 6.3.2 Milestone activities
- 6.4 TSC
- 6.1 Release Management
Meta-release introduction
A CAMARA meta-release is the way CAMARA brings its APIs to market.
A meta-release consists of a set of public releases of curated APIs that applied the CAMARA meta-release process.
The purpose of this section is to define
the milestones of the meta-release
the supporting meta-release process with the detailed activities expected from the different teams
the way to track progress of the Commonalities and ICM releases, the API releases, and the meta-release itself
Meta-release plan
For each meta-release, a meta-release plan provides the dates and progress of the meta-release. It covers the status of
Commonalities and ICM releases
The release of the API versions that are planned to be included in the meta-release.
The list of meta-release plans (or meta-releases for short), whether ongoing, planned or published, can be found here: CAMARA meta-releases.
Meta-release milestones
Meta-release milestones and their associated actions are used to progress and track the status of a meta-release.
A meta-release has 6 milestones, M0 through M6 described below.
For the typical milestone dates of a meta-release, please see the meta-release schedule section below.
All CAMARA teams play their part in the meta-release process. The below table provides, between the milestones, an overview of the activities expected from the various teams to reach these milestones.
More details on these activities for each team are documented in the section on planning and progress tracking for a meta-release.
Commonalities and ICM: release tracking and milestone activities
API Sub Projects: release tracking and milestone activities
Release Management: meta-release tracking and milestone activities
TSC: milestone activities
Details on releasing an API version and the related API versioning are described here: API Release Process.
Milestone / start date | Actors & Activities for next milestone | Timeline | Week Nr |
---|---|---|---|
pre-M0 activities |
|
|
|
M0 | Meta-release kickoff | M0 | 0 |
activities for M1 start @ M0 |
| 2 weeks |
|
M1 | Alpha release Commonalities & ICM | M0 + 2 weeks | 2 |
activities for M2 start @ M1 |
| 7 weeks |
|
M2 | Release candidate Commonalities & ICM | M1 + 7 weeks | 9 |
activities for M3 start @ M1 |
| 9 weeks |
|
M3 | Release candidates for APIs (Code Freeze) | M1 + 9 weeks | 9 |
activities for M4 start @ M3 |
| 9 weeks |
|
M4 | Public releases of APIs | M3 + 9 weeks | 18 |
activities for M5 starts @ public release PR for an API |
| 2 weeks |
|
M5 | Meta-release | M4 + 2 weeks | 20 |
activities for M6 start @ M5 |
| 2 weeks |
|
M6 | Post Meta-release Assessment | M5 + 2 weeks | 24 |
Meta-release schedule
CAMARA meta-releases are scheduled twice per year at approximately 6 month intervals (March and September).
Meta-releases are named SpringYY or FallYY respectively, where YY is the (short) year number. For example Fall24, Spring25, Fall25, etc.
The meta-release process covers 7 milestones, M0 through M6. The below figures provide the typical planning and milestone dates for a Spring or Fall meta-release.
The "typical" meta-release schedule for Spring and Fall meta-releases are depicted in the below figures. NOTE: Actual dates for a given meta-release shall be managed on the dedicated meta-release plans which are listed here: CAMARA meta-releases.
Release contacts
Meta-releases are administered and tracked by
the CAMARA Release Managers, supported by
the release contacts of the Commonalities and ICM working groups
the release contacts of the API Sub Projects
The API Sub Project teams shall put at least 2 contacts on their API release trackers.
RELEASE CONTACT LISTS
The contacts for the Commonalities, ICM and Release Management Working Groups can be found here: CAMARA meta-releases
The contacts per API can be found on the meta-release plans.
All release contacts need to subscribe to the release management mailing list.
All communication on an ongoing meta-release and its progress will be managed through this mailing list, with in copy the maintainers mailing list (link to be added).
M0 and M5 will be announced on the all@lists.camaraproject.org.
Draft messages for the different announcements are prepared on the following page: Release Management announcements
Planning and progress tracking for a meta-release
The planning and status of the ongoing meta-release is discussed in the Release Management working group meetings.
The meta-release planning and status is visible on the meta-release plan created for each meta-release. The meta-release progress data is obtained as follows:
the Commonalities and ICM data is updated directly on the meta-release plan by the respective teams.
the API data is managed by the API Sub Project teams on their API release trackers and pulled into the meta-release plan automatically.
The milestone activities are the activities between the milestones requested from the various teams to plan and provide visibility on the progress of a meta-release. They are described in detail for each team below and are also listed at a higher level in the above meta-release milestones table.
NOTE: in case of differences between this page and the milestone table, this page takes precedence. In case of such differences or missing points or proposed changes or other feedback, please use the Meta-release feedback page.
Release Management
Meta-release tracking
To be able to track a meta-release, the Release Management team first create the meta-release plan under the CAMARA meta-releases page as follow:
Go to the following page Meta-release <meta-release name>, and create a copy, changing the parent page to: CAMARA meta-releases (make sure to tick the "copy files and images" box).
Follow the instructions in red on the copied page.
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 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 release PR for the release candidate 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 release candidate 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
The actual milestone dates and status shall be updated on the meta-release plan when the milestone is achieved.
Milestone status
The overall milestone status is reflected by the milestone status table on the meta-release plan. Its content is managed by the Release Management team and shall have values defined as follows:
Milestone | Before milestone | At milestone |
---|---|---|
M0 | meta-release preparation | kick-off announcement |
M1 (Commonalities & ICM) | alpha release PR | alpha release |
M2 (Commonalities & ICM) | public release PR | public release |
M3 (APIs) | release candidate PR | release candidate |
M4 (APIs) | public release PR | public release |
M5 | meta-release creation | meta-release announcement |
M6 | retrospective preparation | retrospective implementation |
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).
Release tracking
The release tracking for Commonalities and ICM is done by updating the Commonalities and ICM table available on the meta-release plan of the active meta-release.
The following explains the fields of this table and when / how it needs to be updated by the Commonalities and ICM teams:
Field | Field explanation | When to update |
---|---|---|
Target version | the public 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 "Spring25: 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 PR and submit to Release Management
After TSC approval, create approved final alpha release 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 / M4 - 2 weeks
Following API development (M3) and testing (M4), changes to the Commonalities or ICM release candidates may be requested, leading to new release candidates to be reflected on the meta-release page.
The final public releases of Commonalities and ICM shall be available latest 2 weeks before the M4 date. Once released, 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
For Commonalities and ICM, the version and release for a given meta-release are documented on the meta-release plan.
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 can have any number according to the below referenced numbering 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) |
API Sub Projects
Release tracking
API Sub Project teams shall create and update the API release tracker for each of their API version(s) as follows:
Create the API release tracker for the API version planned to be released as described here: API release trackers
With each alpha release or release candidate, the API version and release tag shall be updated on the API release tracker
The actual milestone dates shall be put in the release tracker when the milestone is passed.
When M4 is successfully passed, the link to the public release tag shall be added.
An API version of an API Sub Project should show on the meta-release page as soon as an API release tracker has been created under the API Sub Project's API release tracking page.
If an API release is not visible, please check that the correct meta-release label is added to the API release tracker page.
Milestone activities
The following are the activities of the API Sub Projects between milestones:
M0
Start following the scope definitions of Commonalities and ICM and assess impact on API version
M1
Create API release tracking page for the API if it does not yet exist (it is normally created as part of the API Sub Project creation)
Create API release tracker for the API version to be released
Assess impact of alpha release of Commonalities and ICM scope on API(s)
Define scope of API release:
Record scope in dedicated GitHub issue.
Update the release tracker with the link to the scope issue
Develop API scope through one or more alpha releases
Update the API release tracker with each alpha release tag
Create first release candidate PR and submit to Release Management
After Release Management approval:
Create first release candidate for the API
Update the API release tracker with the release candidate tag
M3
Fix bugs raised by API testers through one or more release candidates
Update API release tracker with each release candidate tag
Submit final release candidate PR to Release Management for checking
After final release candidate PR approval by Release Management:
Create final release candidate and update API release tracker with its tag
Create API public release PR
After TSC approval of the PR
Create public release
Update the API release tracker with public release tag
M4
N/A
M5
Provide feedback on meta-release
M6
TSC
M0: Declare meta-release kickoff
Approve Commonalities and ICM scope
Approve final alpha release PRs of Commonalities & ICM
M1
Approve final release candidate PRs of Commonalities & ICM
M2
Review scope of selected APIs (case by case selection)
M3
Formal approval of the Commonalities & ICM public release PRs
Formal approval API public release PRs
M4
Meta-release approval
M5
Provide feedback on meta-release
Meta-release improvements approval
M6