Meta-Release Planning

This section explains the meta-release plan, schedule and progress reporting on the planed a meta-release.

Meta-release plan

For each meta-release, a meta-release plan shall be created that will visualize the progress of the meta-release. It covers the status of

• Commonalities and ICM releases
• The API versions that are planned to be included in the meta-release.

Meta-release schedule

There are 2 CAMARA meta-releases per year: a Spring meta-release and a Fall meta-release. These are called SpringYY and FallYY respectively, where YY is the (short) year number.

• A meta-release cycle covers 6 months between M0 and M6, including holidays.
• The first CAMARA meta-release is Fall24, followed by Spring25, Fall25, etc.

The following figures provide the typical planning and milestone dates for a Spring or Fall meta-release.

Actual dates for a given meta-release can be found through the list of CAMARA meta-releases.

Spring meta-release schedule

Fall meta-release schedule

Progress reporting on a meta-release

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

Release Management

The Release Management team shall create a 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 update the meta-release page with 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 trackers.
• M4: start acceptance phase for proposed API versions
• M5: publish the meta-release
• M6: Conduct a meta-release retrospective as input to the next meta release

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 page 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)

• 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 ducting the release cycle are the following:

• 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 is achieved. 
• 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 public-release tag. The API Sub-projects shall work with the public-release tags provided at M2.

API Sub-projects

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

• With each alpha or release-candidate API version, the API version and release tag shall be updated, and minimally at M3 and M4.
• The actual milestone dates shall be put in the release tracker when the milestone is passed.
• When M5 is passed, the link to the public-release API package shall be added.

API Sub-projects do not need to edit the meta-release page. It pulls its data from the API release trackers automatically.

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 make sure to add the meta-release label to the API release tracker page as indicated on that 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: