This section explains the processes for meta-release planning, milestone scheduling and progress reporting on the planned a meta-release.
Table of Contents |
---|
...
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
...
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.
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/ 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
...