Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • the CAMARA Release Managers, supported by
  • the release contacts of the Commonalities and ICM working groups
  • the release contacts of the API Sub -projectsProjects

The API Sub -project Project teams shall put at least 2 contacts on their API release trackers.

...

  • 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 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
  • 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 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 Commonalities and ICM data is updated directly on the meta-release plan by the respective teams.
  • the API data is managed by the API Sub -project Project teams on their API release tracke(r) and pulled into the meta-release plan automatically.

...

  • 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".
      • 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 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 Project teams shall create and update the API release tracker for each of their API version(s) as follows: 

...

An API version of an API Sub -project Project should show on the meta-release page as soon as an API release tracker has been created under the API Sub -projectProject's API release tracking page for the API version planned to be released in the meta-release.

...