Meta-release Process

This section explains the processes for meta-release planning, milestone scheduling and progress reporting on the planned a meta-release.

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.

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.

A meta-release cycle covers 6 milestones, M0 through M6. The below figures provide the typical planning and milestone dates for a Spring or Fall meta-release.

Actual dates for a given meta-release shall be managed on the dedicate meta-release plan listed here: CAMARA meta-releases.

Spring meta-release schedule

Fall meta-release schedule

Planning and progress reporting on a meta-release

The following actions are requested from the various teams to plan and provide visibility on the progress of a meta-release.

Release Management

The Release Management team shall create the meta-release plan (page) under CAMARA meta-releases as follows:

• Copy the following page Meta-release <meta-release name>, changing the parent paged to: CAMARA meta-releases (tick the "copy files and images" box).
• Follow the instructions in red on the copied page.

During the meta-release cycle, the Release Management team maintains the meta-release page as follows:

• M0:
  • Request the TSC to declare the meta-release kick-off
  • Request the Commonalities and ICM teams to prepare for M1 the scope definition of what they plan to put in the meta-release
  • Request all API Sub-projects release contacts through the release management mailing list to create the API release tracker for their next planned API version(s) as described here: API release tracking process.
• M4: start apprioval phase for proposed API versions
• M5: publish the meta-release - this is done by ensuring all approved APIs are listed in the meta-release plan and their M5 date and public-release tag and package are available.
• M6: Conduct a meta-release retrospective as input to the next meta release - A release retrospective page is available to all to add comments, feedback and suggestions for improvement.

The actual milestone dates shall be put in the Milestone table when the milestone is achieved.

The status of the ongoing meta-release is discussed in the Release Management working group meetings.

Meta-release progress is visible on the meta-release plan created for each meta-release. The data is obtained as follows:

• 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.

Commonalities and ICM

The Commonalities and ICM teams shall respectively update and maintain their information on the meta-release page per the below.

The following explains the fields of the Commonalities and ICM table on the meta-release page:

• Target version: the public-release version expected to be published as part of the meta-release (latest by M1 but may be put earlier if known).
• Target scope: link to GitHub issue defining the release scope (as soon as issue is created after M1)

• M1 date: actual alpha release milestone date - update also the pre-release tag field

• M2 date: actual release-candidate milestone date - update also the pre-release tag field

• (Pre)release tag: updated with each new pre-release and at each milestone to point to the latest pre-release tag. Different alpha or release-candidate pre-release tags can be put here for usage by other teams, even if milestones are not yet reached.

• M5 date: to be updated on TSC approval of the public-release PR for M5 with creation date of the public-release

• Public-release tag: updated with the public-release tag once available.

The activities of the Commonalities and ICM teams during the release cycle are the following:

• As soon as possible after M1, fix the scope of the release in a dedicated GitHub issue, e.g. called "Commonalities or ICM scope Fall24".
• Whenever a new pre-release is made available, the (Pre-)release tag column shall be updated with the release tag link for the Commonalities and ICM version respectively.
• The actual milestone dates shall be put in the table when the milestone release is approved. 
• Once TSC approval is given at M2, the target public-release version (release tag and release package) shall be created and shall be used by the API Sub-projects to work with. It will also be used for M5 for inclusion in the meta-release and the meta-release page shall be updated with M2 date and the public-release tag.

API Sub-projects

API Sub-project teams shall create and update the API release tracker for each of their API version(s) as follows: 

• With each alpha or release-candidate API version, the API version and release tag shall be updated.
• The actual milestone dates shall be put in the release tracker when the milestone is passed.
• When M4 is sucessfully passed, the link to the public-release API package 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 for the API version planned to be released in the meta-release.

• If an API release is not visible, please check that the correct meta-release label is added to the API release tracker page. 

Release milestone status

The milestone status values on the meta-release pages are managed by the Release Management team and shall have values defined as follows: