Versions Compared

Key

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

...

  • 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 meta-release:

      • Record scope in a dedicated GitHub issue, e.g. called "Spring25: 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

    • To prepare For M1:

    • Create the final alpha release PR and submit to Release Management

    • After TSC approval, create approved final alpha release for of Commonalities & ICM for use by API Sub Projects

    • 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

    • To prepare For M2:

    • 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 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.

  • M2

    • Start the scope definition and alpha release for the next meta-release.

  • M3 / M4 - 2 weeks

    • Following API development (M3) and testing (M4), changes to the Commonalities or ICM release candidates may be requested, leading to new release candidates to be reflected on the meta-release page.

    • The final public releases of Commonalities and ICM shall be available latest 2 weeks before the M4 date. Once released, these will also be used for M5 for inclusion in the meta-release. 

    • For this:

    • Fix bugs/requested changes raised by API testers through one or more release candidates

    • Create the 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

    • After public release, create maintenance release when necessary.

Version and release numbering

...

The following table illustrates the continuous use of release and version numbering and versions across the Commonalities and ICM release process.

release type

version

release number (tag)

release package label

Milestone

N/A

work-in-progresswip

N/A

N/A

M/A

pre-release

x.y.z-alpha.1..n

rm.1 ... rm.n

"pre-release"

M1 (internal pre-release)

pre-release

x.y.z-rc.1..m

rm.n+1 ... rm.n+k

"pre-release"

M2 (internal pre-release)

release

x.y.z

rm.p (p=n+k+1)

"latest"

M4-2 weeks (public)

maintenance release

x.y.z+1..k

rm.p+1 ... rm.p+q

"latest"

After M5 (public)

...