Page Comparison

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

Table of Contents

Meta-release

...

introduction

A CAMARA meta-release is the way CAMARA brings its APIs to market.

A meta-release , a consists of a set of public releases of curated APIs that applied the CAMARA meta-release plan provides the dates and progress process.

The purpose of this section is to define

the milestones of the meta-release

...

Commonalities and ICM releases
The release of the API versions that are planned to be included in 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.

The following table lists the meta-release milestones, and includes a high level view 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

Milestone / start date	Actors & Activities for next milestone	Timeline	Week Nr
pre-M0 activities	Release Management: prepare meta-release plan Commonalities & ICM: define scope and start alpha release development TSC: declare M0 - meta-release kickoff
M0	Meta-release kickoff	M0	0
activities for M1 start @ M0	Commonalities & ICM: fix scope and develop final alpha release for M1 API Sub Groups: check Commonalities and ICM scope definition to assess API impact TSC: approve Commonalities and ICM scope and final alpha release Release Management: Declare M1 - Commonalities and ICM alpha release available	2 weeks
M1	Alpha Commonalities & ICM	M0 + 2 weeks	2
activities for M2 start @ M1	API Sub Groups: align to Commonalities and ICM alpha release and provide feedback Commonalities & ICM: Fix bugs and prepare final release-candidate for M2 TSC: approve Commonalities and ICM final release-candidate Release Management; declare M2 - Commonalities and ICM release-candidate available	7 weeks
M2	Release-candidate Commonalities & ICM	M1 + 7 weeks	9
activities for M3 start @ M1	API Sub Projects: prepare API scope and develop alpha releases, ending by the first release-candidate for M3 TSC: review scope of APIs (case by case selection) Release Management: check API readiness of each API and declare M3 - all API first release-candidates available	9 weeks
M3	Release-candidate APIs (Code Freeze)	M1 + 9 weeks	9
activities for M4 start @ M3	API Sub Projects: fix bugs and prepare public-release Commonalities & ICM: prepare public-release Release Management: check API readiness of each API and declare M4 - all API public-releases available TSC: give formal approval of Commonalities, ICM and API (case-by-case) public-releases	9 weeks
M4	Public-release APIs	M3 + 9 weeks	18
activities for M5 starts @ public-release PR for an API	Release Management: prepare and declare M5 - meta-release availability TSC: approve meta-release for M5	2 weeks
M5	Meta-release	M4 + 2 weeks	20
activities for M6 start @ M5	Commonalities & ICM: assess meta-release and provide feedback API Sub Groups: assess meta-release and provide feedback Release Management: assess meta-release, create improvement plan and declare M6 - post-release assessment available TSC: approve improvement plan for M6	2 weeks
M6	Post Release Assessment	M5 + 2 weeks	24

Processes

All CAMARA teams play their part in the meta-release process. An overview of the activities per team is shown in the above table.

The details on the activities for each team can be found in the below process descriptions:

The process to manage a meta-release is described here: Meta-release Process
The process for the Commonalities and ICM teams is described here: Commonalities and ICM release process
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 approximately 6 month intervals (March and September).

...

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.

...

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 release for the meta-release:
  - Record scope in a dedicated GitHub issue, e.g. called "Fall24: 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
- Create final alpha release PRs and submit to Release Management
- After TSC approval, create approved final alpha release for Commonalities & ICM
- 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
- 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.
- Start the scope definition and alpha release for the next meta-release.
M3 and M4
- During API development, 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 public-release PR of the Commonalities and ICM will only be created latest 2 weeks before the M4 date. Once committed, these will also be used for M5 for inclusion in the meta-release.
- Fix bugs raised by API testers through one or more release - candidates
- Create 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
M5
- Provide feedback on meta-release
M6

Version and release numbering

PROPOSAL FOR DISCUSSION

Version numbering

For Commonalities and ICM, the version is defined here ????

...

for a given meta-release is documented on the meta-release plan.

The version numbering scheme follows Semantic Versioning 2.0.0.

...

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 -releasereleases, no version extension is allowed

The following table provides the overview of the release versioning and numbering scheme through the release cycle.

...

release process.

Release type	Version number	Release number / release number (tag)	Version can be releasedMilestone
alpha release	x.y.z-alpha.m	rx.y.z-alpha.m	Yes M1 (internal pre- M1release)
release - candidate	x.y.z-rc.n	rx.y.z-rc.n	Yes M2 (internal pre- M2release)
public - release	x.y.z	rx.y.z	Yes (M5)

API Sub Projects

Release tracking

...

Create the API release tracker for the API version planned to be released as described here: API release tracking process
With each alpha release or release - candidate API version, 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 for the API version planned to be releasedtracking 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 actions for 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 final impact of final alpha release -candidates 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 link
- 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 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

...

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

...

Versions Compared

Old Version 71

New Version 72

Key