...
NOTE: in case of differences between this page and the milestone table, or in case of missing points or proposed changes or other feedback, please use the Meta-release feedback page.
Release Management
During the meta-release cycle, the Release Management team actions for progressing the meta-release are the following:
- Before M0, the Release Management team shall create the meta-release plan (page) under CAMARA meta-releases as follows:
- Copy the following page Meta-release <meta-release name>, changing the parent paged to: CAMARA meta-releases (tick the "copy files and images" box).
- Follow the instructions in red on the copied page.
- Request the TSC to declare the meta-release kick-off.
During the meta-release cycle, the Release Management team maintains the meta-release page as follows:
- M0: 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 release contacts to create the API release tracker for their next planned API version(s) as described here: API release tracking process.
- the Outreach Committee to start preparation of marketing activities based on information in the meta-release plan
- announce the meta-release kick-off on the CAMARA mailing list (all@lists.camaraproject.org). This announcement indicates:
- M1
- 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.
- M2
- 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.
- Check that the meta-release plan is updated with
- the final release-
- candidate information of Commonalities and ICM. Announce M2 milestone once the meta-release page is updated with the Commonalities and ICM release-candidate tags.
- M3
- 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.
- M4
- for all APIs, check readiness of final release-candidate API
- PRs. 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.
- Once available, check final API release-candidate PR and, if OK, approve PR. for all API public-release PRs, check if OK and ask for formal TSC approval. Announce M4 milestone when all API public-releases are approved by TSC.
- M5
- 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
- M6
- conduct a meta-release retrospective as input 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. Improvement proposals are submitted for approval to TSC and implemented for the next meat-release.
The actual milestone dates and status shall be updated on the meta-release plan when the milestone is achieved.
...
- 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 after 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 during the release cycle are the following:
- before M0:
- Starting from the M2 of the previous meta-release, prepare the scope definition for the upcoming meta-release, and start implementation in one or more alpha releases.
- M0
- As soon as possible after
- M0, fix the scope definition of the release for the meta-release:
- Record scope in a dedicated GitHub issue, e.g. called "Fall24: Commonalities
- / ICM scope
- ".
- 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 approved.
- Once TSC approval is given at M2, the target public-release version (release tag and release package) shall be created and the meta-release page shall be updated with M2 date and the public-release tag. This public-release
- 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 release tracker on meta-release page with each release-candidate
- Create final release-candidate PR and submit to Release Management for checking
- After TSC approval:
- Create the final release-candidate for Commonalities & ICM
- Update the meta-release page for Commonalities & ICM with release-candidate tag
- This final release-candidate shall be used by the API Sub-projects to work with for their API release-candidate development.
- 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. Hence the public-release PR of The commonalities and ICM will only be created latest 2 weeks before the M4 date. It 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
API Sub-projects
API Sub-project teams shall create and update the API release tracker for each of their API version(s) as follows:
...