This section explains the processes for meta-release planplanning, schedule milestone scheduling and progress reporting on the planed planned a meta-release.
| Table of Contents |
|---|
Meta-release plan
For each meta-release, a meta-release plan shall be created that will visualize the 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
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.
...
Actual dates for a given meta-release can shall be found through the list of 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 a the meta-release plan (page) under under CAMARA meta-releases 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 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 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 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.
...
- 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 ducting 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 achievedapproved.
- 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. 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 version(s) as follows:
- With each alpha or release-candidate API version, the API version and release tag shall be updated, as well as the M3 date (for alpha releases) or M4 date (for release-candidates).
- The actual milestone dates shall be put in the release tracker when the milestone is passed.
- When M5 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:
...