This section explains the processes for meta-release planning, milestone scheduling and progress reporting on the planned a meta-release.
Table of Contents |
---|
...
- 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 All CAMARA teams play their part in the meta-release milestones, and includes a high level view process. The below table provides, between the milestones, an overview 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
Details on releasing an API version and the related API versioning are described here: API Release Process.
Milestone / start date | Actors & Activities for next milestone | Timeline | Week Nr |
---|---|---|---|
pre-M0 activities |
| ||
M0 | Meta-release kickoff | M0 | 0 |
activities for M1 start @ M0 |
| 2 weeks | |
M1 | Alpha release Commonalities & ICM | M0 + 2 weeks | 2 |
activities for M2 start @ M1 |
| 7 weeks | |
M2 | Release - candidate Commonalities & ICM | M1 + 7 weeks | 9 |
activities for M3 start @ M1 |
| 9 weeks | |
M3 | Release -candidate candidates for APIs (Code Freeze) | M1 + 9 weeks | 9 |
activities for M4 start @ M3 |
| 9 weeks | |
M4 | Public -release releases of APIs | M3 + 9 weeks | 18 |
activities for M5 starts @ public - release PR for an API |
| 2 weeks | |
M5 | Meta-release | M4 + 2 weeks | 20 |
activities for M6 start @ M5 |
| 2 weeks | |
M6 | Post Release Meta-release Assessment | M5 + 2 weeks | 24 |
...
Meta-release schedule
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).
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 shall be managed on the dedicate meta-release plan which are listed here: CAMARA meta-releases.
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.
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 shall be managed on the dedicated meta-release plans which are listed here: CAMARA meta-releases.
Plantumlcloud | ||||||||
---|---|---|---|---|---|---|---|---|
|
Plantumlcloud | ||||||||
---|---|---|---|---|---|---|---|---|
|
Release contacts
Meta-releases are administered and tracked by
...
- M0
- Announce the meta-release kick-off 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 tracking processtrackers.
- the Outreach Committee to start preparation of marketing activities based on information in the meta-release plan
- Once available, check the final alpha releases PR of Commonalities & ICM and their release asset availability. If OK, submit to TSC for approval.
- After TSC approval, announce M1 on release management and maintainers mailing lists.
- Announce the meta-release kick-off on the CAMARA mailing list (all@lists.camaraproject.org). This announcement indicates:
- M1
- Check for Commonalities and ICM that all release assets are available in their final release - candidate PRs.
- If OK, request TSC to approve creation of the final release - candidate of Commonalities and ICM.
- After TSC approval, and update of the meta-release plan with the final release - candidate tags of Commonalities and ICM, announce M2 milestone.
- M2
- From M1, for all APIs, once available, check the first API release - candidate PR and, if OK, approve PR.
- Announce M3 milestone once all approved API release - candidates have update their API release tracker.
- M3
- For all APIs, once available, check final API release - candidate PR and, if OK, approve PR. Approval can start as soon as an API Sub Project indicates "M4: ready for RM" on the API release tracker in the comments field. It is not necessary to wait for the actual M4 date if an API release is ready before.
- For all APIs, once available, check API public - release PR, and, if OK, ask for formal TSC approval.
- Announce M4 milestone when all API public - releases are approved by TSC.
- M4
- Check that all API release trackers are updated with their public - release tag for the meta-release.
- Propose meta-release content to TSC.
- After TSC approval, publish the meta-release.
- Announce the M5 meta-release 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
...
Milestone | Before milestone | After milestone |
---|---|---|
M0 | kick-off preparation | kick-off done |
M1 | alpha PR | alpha for M2 |
M2 | release - candidate PR | release - candidate for M4 |
M3 | API first release - candidate PR | API first release - candidate for M4 |
M4 | API final release - candidate PR API public - release PR | API final release - candidate API public - release for M5 |
M5 | meta-release preparation | meta-release published |
M6 | retrospective preparation | retrospective done |
...
Field | Field explanation | When to update | |
---|---|---|---|
Target version | the public - release version targeted for the meta-release | at M0 or when the target scope issue is created | |
Target scope | link to GitHub issue defining the release scope | when the issue is created | |
M1 date | M1 / date | date of pre-release or actual final alpha release milestone date | when each alpha release is created (before M1) |
M2 / date | date of pre-release or actual final release - candidate milestone date | when public-each release candidate is created (before M2) | |
(Pre)release tag | link to latest pre-release (alpha or release candidate) | when a new pre-release is created | |
M5 / date | actual final public - release milestone date | when the public - release is created | |
Public - release tag | link to final public - release tag | when the public - release is created |
Milestone activities
...
- 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
- As soon as possible after M0, fix the scope definition for the release for the meta-release:
- 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 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
- M4
- M5
- Provide feedback on meta-release
- M6
...
- Create the API release tracker for the API version planned to be released as described here: API release tracking processtrackers
- With each alpha release or release candidate, 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.
...
- 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 impact of alpha release 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
- 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 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
...