...
The following explains the fields of this table and when / how it needs to be updated by the Commonalities and ICM teams:
| 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 | actual final alpha release milestone date | when alpha release is created (before M1) |
M2 date | actual final release-candidate milestone date | when public-release is created (before M2) |
(Pre)release tag | link to latest pre-release | when a new pre-release is created |
M5 date | actual final public-release milestone date | when public-release is created |
| Public-release tag | link to final public-release | when public-release is created |
Milestone activities
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.
- 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
- As soon as possible after M0, fix the scope definition for the release for the meta-release:
- 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 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
- M5
- Provide feedback on meta-release
- M6
Version and release numbering
PROPOSAL FOR DISCUSSION
Version numbering
For Commonalities and ICM, the version is defined here ????
Open question: is there any place where the version is captured ? a config file or other ?
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 "v" in the release tag: vx.y.z
- for alpha or release candidates it is post-fixed with the version extensions: vv.y.z-alpha.m or vx.y.z-rc.n
- for public release no version extension is allowed
The following table provides the overview of the release versioning and numbering scheme through the release cycle.
| Stage in release process | Version number | Release number / release tag | Version can be released |
|---|---|---|---|
| alpha | x.y.z-alpha.m | vx.y.z-alpha.m | Yes (internal - M1) |
| release-candidate | x.y.z-rc.n | vx.y.z-rc.n | Yes (internal - M2) |
public-release | x.y.z | vx.y.z | Yes (M5) |
API Sub Projects
Release tracking
...