Meta-release Process

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

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 overview on the progress of the meta-release. It covers

• The meta-release schedule with milestone dates

• Commonalities and ICM release progress

• The release progress of the API versions included in the meta-release

• The release contacts for the above assets

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 define the process guiding the development of the meta-release assets. 

• A meta-release has 7 milestones, M0 through M6 described below. 

  • M1, M2 and M4 concern the Commonalities and ICM guidelines development and release

  • M3 and M4 concern the API development and release

  • M0, M5 and M6 concern the meta-release delivery

• For the typical milestone dates of a meta-release, please see the meta-release schedule section below.

Assets per milestone

The assets (guidelines and APIs) expected to be developed during the meta-release cycle for each milestone are reflected in the following table.

For a given meta-release, the details for each particular asset is available on the meta-release plan.

Team activities per milestone

All CAMARA teams play their part in the meta-release process. The below table provides an overview of the activities expected from each team before each milestone. 

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. 

Meta-release schedule

CAMARA meta-releases are scheduled twice per year at 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 are managed on the dedicated meta-release plans which are listed here: CAMARA meta-releases.

Spring meta-release schedule

Fall meta-release schedule

API release trackers

The progress of API version development and its releases throughout the meta-release cycle is communicated through API release trackers.

An API release tracker is a Wiki page that contains information about the API which is used to create the overview of the API status on the meta-release plan.

An API release tracker is created for each API version. They are owned and maintained by the API Sub Projects throughout the life-cycle of the API version, both during a given meta-release cycle and after for maintenance releases.

More information about the API release trackers can be found here: API release trackersPreview

Release contacts and communication

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.

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 the above Release Management mailing list, with in copy the codeowners mailing list.

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 either comments on the page, the Meta-release feedback page or create a documentation issue in the Release Management repository in GitHub.

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 (M0) 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.

  • After TSC approval, announce M1 on the release management and maintainers mailing lists.

• M1

  • Invite all APIs to define their scope and target version for the meta-release in line with Commonalities and ICM alpha releases, and to update the corresponding API release tracker

  • Once M2 release candidate PR is available, review Commonalities and ICM. 

  • Invite TSC to review the M2 release candidate PR

  • Once OK, request TSC to approve creation of the M2 release candidate of Commonalities and ICM. 

  • After TSC approval, check the update of the meta-release plan with the final release candidate tags of Commonalities and ICM, and announce M2 milestone.

• M2

  • From M2, for Commonalities and ICM,

    • Review the M4 release PR for the public release once available.

    • Invite TSC to review the M4 public release PR

    • Once OK, approve M4 public release PR and follow the finalization up to the release creation and the update of the meta-release plan with the public release references.

  • From M1, for all APIs,

    • Check the availability of the API scope issue

    • As soon as the M3 release PR is available, create the M3 review issue.

    • Check the M3 release PR for the release candidate API version.

    • Invite TSC for selected API M3 release PR reviews.

    • Once OK, approve the M3 release PR and follow the finalization up to the release creation and the update of its API release tracker (as indicated in the M3 review issue).

  • Once all approved API release candidates are available, inform TSC, and declare and announce the M3 milestone.

• M3

  • For all APIs,

    • as soon as the M4 release PR for the public API version is available, create the M4 review issue and the check the M4 release PR.

    • Once OK, approve the M4 release PR and follow the finalization up to the release creation and the update of its API release tracker (as indicated in the review issue).

  • Once all approved API public releases are available, inform TSC and declare and announce the M4 milestone.

• M4

  • Update the meta-release plan to its final format showing all API release trackers with their public release tag.

  • Propose meta-release for approval to TSC.

  • Request the TSC to declare the M5 meta-release availability.

  • After TSC approval, announce the M5 meta-release availability 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 during the meta-release cycle and update at each change or milestone.

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:

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 approval, create alpha release of Commonalities & ICM for use by API Sub Projects

  • Update the meta-release plan with the alpha release tag and date

• 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 approval, create release candidate for Commonalities & ICM

  • Update the meta-release plan with the release candidate release tag and date. 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.

  • 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 public releases of Commonalities and ICM shall be available latest 2 weeks before the APIs M4 date. Once released, these will also be used for M5 for inclusion in the meta-release. 

  • For M4:

  • Fix bugs/requested changes raised by API testers through one or more release candidates

  • Create the M4 public release PR for Commonalities & ICM

  • After Release Management review 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 shall follow the same rules as the below referenced API versioning scheme, e.g. for alpha, release-candidate and public versions.

The API version numbering is described here: API versioningPreview

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

The following table illustrates the use of release and version numbering across the Commonalities and ICM release process.