Versions Compared

Key

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

...

FieldField explanationWhen to update

Target version

the public - release version targeted for the meta-releaseat M0 or when the target scope issue is created

Target scope

link to GitHub issue defining the release scopewhen the issue is created

M1 date/ date

date of pre-release or actual final alpha release milestone datewhen each alpha release is created (before M1)

M2 / date

date of pre-release or actual final release - candidate milestone datewhen 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 datewhen the public - release is created
Public-release taglink to final public - release tagwhen 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
  • 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

...