...
Meta-release | The name of the meta-release, e.g. Fall24. Put N/A if the API version is planned to be an initial public release version only outside of the meta-release. |
API name | The API name. See For the definition of "API name" on this page see: API Release Process, e.g. geofencing |
| Group | The name of the API Sub project or the repository for the API Sub Project, e.g. DeviceLocation |
| Repository | The shortened link to GitHub repository for the API Sub Project, e.g. DeviceLocation |
| Target version | The API version that you plan to publish in the indicated meta-release, e.g. 0.5.0, 1.0.0, 1.1.0, etc. |
| Target scope | The shortened link to a GitHub issue called "Scope for version <x.y.z>" which needs to be created latest at M1 and resolved by M3 e.g. DeviceLocation/issues/58 |
| Target maturity | Indicates the maturity of the public API version that is targeted in the upcoming meta-release: choose one of "initial" or "stable". |
| Readiness checklist | The shortened link to the API readiness checklist for the API version. The template of the checklist can be found here: (link to release management repo tbd) API-Readiness-Checklist.md |
| M3 date | The date when of the availability of the first release-candidate API version is ready. This is the starting point for creating the final release of the release-candidate API version for M4. After this dateafter approval of its release PR. Between M3 and M4 dates, only bug fixes and necessary non-breaking changes can be made to the APIthrough additional release-candidates. Format is yyyy-mm-dd |
| M4 date | The date when of the availability of the final release-candidate API version for M5 submission is ready. This is the starting point for creating the public-release API version for M5. Once this date is provided by the API project teamrelease of the target public API version after approval of its release PR. For approval, the Release Management team can will check the release -candidate API version PR for acceptance and submit it to the TSC for approval. Format is yyyy-mm-dd |
| API version | The version of the latest pre-release (alpha or release-candidate) API version to be updated at M3 and M4 date, e.g. 0.2.0_alpha.3, 0.10.0-rc.2, 0.10.1, 1.0.0-rc.5, etc.) |
| pre-release tag | The shortened link to the release tag of the latest pre-release (alpha or release-candidate) for the API version e.g. QualityOnDemand/releases/tag/r0r1.10 |
| M5 date | The date by which the Release Management team has checked the release-candidate API version provided at the M4 date and the API is approved by the TSC. The link to the PR for public-release API version shall be included in this field when available After this date, if approval is obtained, the API Sub Project shall commit the PR of the public-release API version and its release assets for use in the meta-release. Format is yyyy-mm-dd. The link to the PR shall be removed after the commit is done. |
| public-release tag | The The shortened link to the release tag of the public API version. This field is updated once the public release has been created, e.g. QualityOnDemand/releases/tag/r1.0 15 |
| Comments | Field for exchanging information with RM team, for example M1: Commonalities/ICM alpha release-candidate ready for approval / approval by TSC M2: Commonalities/ICM rc public version ready for approval / approved by TSC M3: alpha API release-candidate ready for approval / approved by RMby RM M3: checked by RM - NOK - missing sunny test cases M4: API public version ready for RM M4: API public version ready for RM / ready for approval by TSC / approved by approved by TSC M5: publicmeta-release doneclosed M5: API version retirement planned by yyyy-mm-dd. |
| Contacts | Contact names for the API release: name1 @name2 |
...