...
Field | Field explanation | When to update |
|---|---|---|
Target version | the public release version targeted for the meta-release | at M0 or when the target scope issue is created |
Target scope | link to GitHub issue defining the release scope | when the issue is created |
M1 / date | date of pre-release or actual final alpha release milestone date | when each alpha release is created |
M2 / date | date of pre-release or actual final release candidate milestone date | when each release candidate is created |
(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 date | when the public release is created |
Public release tag | link to final public release tag | when the public release is created |
Patch date | publication date of patch release (if any) | if a patch to the public release is created |
Milestone activities
The activities of the Commonalities and ICM teams during the release process are the following:
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 "Fall24Spring25: 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 M1:
Create final alpha release PRs PR 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
To prepare 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 and / M4 - 2 weeks
During Following API development (M3) and testing (M4), 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 final public release PR releases of the Commonalities and ICM will only shall be created available latest 2 weeks before the M4 date. Once committedreleased, 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
Version and release numbering
Version numbering
For Commonalities and ICM, the version and release for a given meta-release is are documented on the meta-release plan.
The version numbering scheme follows Semantic Versioning 2.0.0.
Release numbering
A Commonalities or ICM release is tagged with a GitHub release tag named as follows:
it is numbered with the version number: x.y.z
is prefixed with "r" in the release tag: rx.y.z
for alpha releases or release candidates it is post-fixed with the version extensions: rx.y.z-alpha.m or rx.y.z-rc.n
for public releases, no version extension is allowed
The following table provides the overview of the release versioning and numbering scheme through the release process.
...
Release type
...
Version number
...
Release number (tag)
...
Milestone
...
NOTE: Version and release numbering follow separate schemes. A given release concerns a specific version of the released artifacts.
Version numbering
For Commonalities and ICM, their version is documented in a dedicated file “VERSION.yaml” in the home folder of the repository. The syntax contains “version: <version>” where version can have any number according to the below referenced numbering scheme, e;g. for alpha, release-candidate and public versions.
The version numbering follows the same scheme as for APIs as described here: API versioning
Release numbering
The release numbering follows the same scheme as for API releases as described in the section on API release numbering here: API Release Process .
The following table illustrates the continuous release numbering and versions across the Commonalities and ICM release process.
release type | version | release number (tag) | release package label | Milestone |
|---|---|---|---|---|
N/A | work-in-progress | 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 |
M2 (internal pre-release)
rm.p (p=n+k+1) | "latest" | M4-2 weeks (public) | |
maintenance release | x.y.z |
rx.y.z
+1..k | rm.p+1 ... rm.p+q | "latest" | After M5 (public) |
API Sub Projects
Release tracking
...