Page History

...

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:

• M0M0:
  • 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
  • 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.
  • M2M2:
    • check for Commonalities and ICM that all release assets are available in their
    public-release PR. If
    • final release-candidate PRs. If OK, request TSC to approve creation of
    public
    • the final release-
    release
    • candidate of Commonalities and ICM.
     Check
    • Check that the meta-release plan is updated with
    public
    • the final release-
    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
      M4: start approval phase for proposed
      • release-candidate API
      versions -
      • 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
      M5: publish
      • the meta-release
      - this is done by ensuring all approved APIs are listed in
      • . Propose meta-release content to TSC. After TSC approval, publish the meta-release
      plan and their M5 date and public-release tag and package are available.
      • . Announce the M5 meta-release on all@lists.camaraproject.org 
    • M6
      • conduct
      M6: Conduct
      • a meta-release retrospective as input for the next meta release
      - A
      • with all teams. A meta-release
      retrospective
      • 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
      M1
      • M0, fix the scope definition of the release for the meta-release:
        • Record scope in a dedicated GitHub issue, e.g. called "Fall24: Commonalities
      or
      • • / ICM scope
      Fall24
      • • ".
    • 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. 
    • • • 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
      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
      • 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: 

    ...