...
| Table of Contents |
|---|
UPDATE PROPOSAL
Introduction
The purpose of this document is to describe the cadence, processes, milestones, and associated tasks used in the CAMARA release cycle. See CAMARA meta-releases for information and schedule for specific releases.
Release Milestones
Release milestones and their associated tasks, are used to track the status of the meta-release. The milestones and management tasks used in the release process are described in the table below.
LATEST (back to 1 column for actions) add actor and split groups of actions per actore
| Milestone | Actors & Actions for next milestone | Timeline | Week Nr |
|---|---|---|---|
| M0 - meta-release kickoff | M0 | 0 | |
Release Management
Commonalities & ICM
TSC
| 2 weeks | ||
M1 - Draft Commonalities & ICM | M0 + 2 weeks | 2 | |
Commonalities & ICM
TSC
| 10 weeks | ||
M2 - Final Commonalities & ICM | M1 + 10 weeks | 12 | |
API Sub-projects
TSC
| 8 weeks | ||
M3 - Draft APIs | M1 + 8 weeks | 10 | |
API Sub-projects
TSC
| 10 weeks | ||
M4 - Final APIs | M3 + 10 weeks | 20 | |
Release Management
| 2 weeks | ||
M5 - Meta Release | M4 + 2 weeks | 22 | |
Release Management
| 2 weeks | ||
M6 - Post Release | M5 + 2 weeks | 24 |
ORIGINAL
| Milestone | Milestone Name | Actions to achieve milestone | Timeline | Week number |
|---|---|---|---|---|
| Kickoff - M0 | Start of release cycle. | M0 | 0 | |
M1 | Initiate Commonalities & ICM |
| M0 + 2 week | 2 |
M2 | Finalize Commonalities & ICM |
| M1 + 10 weeks | 12 |
M3 | Initiate Sub-projects / APIs |
| M1 + 8 weeks | 10 |
M4 | Finalize Sub-projects / APIs |
| M3 + 10 weeks | 20 |
M5 | Meta Release |
| M4 + 2 weeks | 22 |
M6 | Post- Release |
| M5 + 2 weeks | 24 |
Insert separate milestone lines
| Milestone | Milestone Name | Actions to achieve next milestone | Timeline | Week number |
|---|---|---|---|---|
| Kickoff - M0 | Start of release cycle. | M0 | 0 | |
| 2 weeks | |||
M1 | Initiate Commonalities & ICM | M0 + 2 weeks | 2 | |
| 10 weeks | |||
M2 | Finalize Commonalities & ICM | M1 + 10 weeks | 12 | |
| 8 weeks | |||
M3 | Initiate Sub-projects / APIs | M1 + 8 weeks | 10 | |
| 10 weeks | |||
M4 | Finalize Sub-projects / APIs | M3 + 10 weeks | 20 | |
| 2 weeks | |||
M5 | Meta Release | M4 + 2 weeks | 22 | |
| 2 weeks | |||
M6 | Post- Release | M5 + 2 weeks | 24 |
separate action in 2 columns (but would need a 3rd for RM actions)
| Milestone | Milestone Name | Actions Commonalities & ICM | Actions API Sub-projects | Timeline | Week Nr |
|---|---|---|---|---|---|
| Kickoff - M0 | Start of meta-release | M0 | 0 | ||
| 2 weeks | ||||
M1 | Initial Commonalities & ICM | M0 + 2 weeks | 2 | ||
| 10 weeks | ||||
M2 | Final Commonalities & ICM | M1 + 10 weeks | 12 | ||
| 8 weeks | ||||
M3 | Initial Sub-projects / APIs | M1 + 8 weeks | 10 | ||
| 10 weeks | ||||
M4 | Final Sub-projects / APIs | M3 + 10 weeks | 20 | ||
| 2 weeks | ||||
M5 | Meta Release | M4 + 2 weeks | 22 | ||
| 2 weeks | ||||
M6 | Post Release | M5 + 2 weeks | 24 |
merge milestone and milestone name columns
| Milestone | Actions Commonalities & ICM | Actions API Sub-projects | Timeline | Week Nr |
|---|---|---|---|---|
| M0 - meta-release kickoff | M0 | 0 | ||
| 2 weeks | |||
M1 - Initial Commonalities & ICM | M0 + 2 weeks | 2 | ||
| 10 weeks | |||
M2 - Final Commonalities & ICM | M1 + 10 weeks | 12 | ||
| 8 weeks | |||
M3 - Initial Sub-projects / APIs | M1 + 8 weeks | 10 | ||
| 10 weeks | |||
M4 - Final Sub-projects / APIs | M3 + 10 weeks | 20 | ||
| 2 weeks | |||
M5 - Meta Release | M4 + 2 weeks | 22 | ||
|
M6 - Post Release
LATEST
Actors & Actions for next milestone
Timeline
Week Nr
Release Management
- Prepare meta-release page
Commonalities & ICM
- Define scope of release.
- Record scope in dedicated GitHub issue.
- Submit scope for TSC review
- Develop Commonalities & ICM scope through one or more alpha release(s)
- Update release tracker on target meta-release page with each alpha release
- Submit final alpha releases PR for TSC review:
- If OK: create final alpha releases for Commonalities & ICM
TSC
- Review final alpha releases of Commonalities & ICM
M1 - Draft Commonalities & ICM
Commonalities & ICM
- Fix bugs raised by users through one or more release-candidates
- Update release tracker on target meta-release page with each release-candidate
- Submit final release-candidates PRs for TSC approval
- If approved:
- Create final release-candidates for Commonalities & ICM
- Prepare public-release PR for Commonalities & ICM for M5
TSC
- Approval of final release-candidates PRs of Commonalities & ICM
M2 - Final Commonalities & ICM
API Sub-projects
- Define scope of API release.
- Record scope in dedicated GitHub issue.
- Submit scope for TSC review
- Create API release tracker for the API version
- Develop API scope through one or more alpha release(s)
- Update the API release tracker with each alpha release
- Submit final alpha API release PR for TSC review:
- If OK: create final alpha releases for the API
TSC
- Review final alpha release of the API
M3 - Draft APIs
M1 + 8 weeks
API Sub-projects
- Fix bugs raised by API testers through one or more release-candidates
- Update API release tracker with each release-candidate
- Submit final API release-candidates PR for TSC approval
- If approved:
- Create final API release-candidate
- Prepare API public-release PR for M5
TSC
- Approval of final API release-candidate PR
M4 - Final APIs
M3 + 10 weeks
Release Management
- For Commonalities and ICM, check that all release assets are available for acceptance in the meta-release
- For each API release-candidate, check that all release assets are available for acceptance in the meta-release
- Get TSC approval
- Publish the meta-release
M5 - Meta Release
Release Management
| 2 weeks | |||
M6 - Post Release | M5 + 2 weeks | 24 |
Horizontal milestones
...
- Scope of Work Products clarified and recorded in dedicated issue.
- Identify commonalities work products.
- Create alpha release for Commonalities & ICM
- Create initial PRs for commonalities.
- Agree on the scope of commonalities.
- TSC review.
Release cadence
CAMARA meta-releases are scheduled twice per year at approximately 6 month intervals (March and September). Meta-releases are named after major world cities in alphabetical order.
Release contacts
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 teams can put their release contact names on the Release Contacts (Maintainers) page.
Team release contacts need to subscribe to the release management mailing list.
Process
Details on API versioning and the link with the release management is described here: Releasing API versions
Meta-release (M0, M5, M6)
A Meta-release has 6 milestones, M0 through M6 described above. For the milestone dates per meta-release, please see the Meta-release planning.
The Release Management team has the following activities for each meta-release:
- Create the meta-release page under CAMARA meta-releases
- Inform all team's release contacts through the release management mailing list that they need to provide input to the meta-release page.
- Declare the kick-off of the meta release.
- Prepare starting at M4 and publish the meta-release at M5.
- Conduct a meta-release retrospective as input to the next meta release
At M0 preparation,
- the Commonalities and ISM teams shall update the meta-release page with the information of what they plan to contribute to the meta-release, and with the status updates during the meta-release cycle.
- all API Sub-project teams shall create their release tracker page(s) for the API version(s) they plan to contribute to the meta-release
Release milestone status
The ongoing meta-release status is discussed in the Release Management working group meetings and recorded on the meta-release page.
The milestone status values are defined as follows:
...
Commonalities & ICM (M0, M1, M2)
The Commonalities and ICM teams shall respectively update the related meta-release page table as follows:
- The (Pre-)Release tag column shall be updated with the latest pre-release tag link to the API version whenever a new pre-release is made available.
- The actual milestone dates shall be put in the table when the milestone is achieved.
- The link to the release package shall be added at each pre-release change, and at M2 (and is the same at M5).
- When M2 is passed and TSC approval is given, the target public-release version shall be created and the link put in the (Pre-)Release package column.
APIs (M0, M3, M4)
API Sub-project teams shall update the table for APIs as follows:
- The(Pre-)Release tag column shall be updated with the latest pre-release API version in use by the team.
- The actual milestone dates shall be put in the table when the milestone is passed.
- The link to the release package shall be added at each pre-release change, and minimally at M3, M4, and the final at M5.
- When M5 is passed, the target release API version shall be put in the(Pre-)Release tag column.
For sub-projects that contain multiple APIs in separate files,
- A folder per API shall be created for its development, ONLY if all APIs are managed under the same version, else a separate API Sub-project shall be created
- The API version used in the API release asset naming for pre- and public releases include the API name. However, the API OAS definition file only has the semver API version.
API version tag
the main branch always contains the latest API version. It is meant for development.
API versions can be created through alpha or release-candidate API version tags and API version release packages. These pre-releases become more stable with increasing API versions.
API version release package
Release packages shall be creates using the GitHub release process.
Each release package shall include the release notes using the provided template.
Each release package has a tag: pre-release or latest.
Meta-release roadmap
...