The CAMARA release process requires each API Sub Project to plan and track their API versions so that the meta-release can be planned.
...
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 version only outside of the meta-release. | |||||||
API name | The API name. 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 under which the repository for of the API Sub Projectis managed, 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. Patch versions are | |||||||
| Maturity level | Indicates the maturity of the public API version that is targeted in the upcoming meta-release: choose one of "initial" or "stable". | |||||||
| 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: Readiness checklist |
| ||||||
| M3 date | The date of the availability of the release of the release-candidate API version after approval of its release PR. Between M3 and M4 dates, only bug fixes and necessary non-breaking changes can be made through additional release-candidates. Format is yyyy-mm-dd | |||||||
| M4 date | The date of the availability of the release of the target public API version after approval of its release PR. For approval, the Release Management team will check the release PR for acceptance and submit it to the TSC for approval. Format is yyyy-mm-dd | |||||||
Edit the macro and put the URL of the API-Readiness-Checklist.md | ||||||||
| API version | The version of the latest (pre-)release (alpha or, release-candidate or public release) API version. This field is to be updated at M3 and M4with each (pre-)release date, e.g. 0.2.0 _-alpha.3, 0.10.0-rc.2, 0.10.1, 1.0.0-rc.5, etc.) | |||||||
| M3 date | The date of the release PR availability or the date of the release of the API version after approval of its release PR. Update this field with each pre-release created between M1 and M3. The last pre-release date is the M3 date of the API. Format is yyyy-mm-dd. | |||||||
| M3 release tag | The shortened link to the release PR when available for review, and once released, 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/r1.10M5 . The last pre-release is for the M3 milestone. | |||||||
| M4 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-releaseof the release PR availability or the date of the release of the API version after approval of its release PR. Update this field with each release created between M3 and M4. The last release date is the M4 date of the API. Format is yyyy-mm-dd. | |||||||
| M4 release | The shortened link to the PR shall be removed after the commit is done. | public-release tag | The release PR when available for review, and once released, the shortened link to the release tag of the latest (pre-)release (release-candidate or public) for the API version . This field is updated once the public release has been created, e.g. r1.10. The last release is for the M4 milestone. | |||||
| RM review | Review status and short link to the review issue for the M3 and M4 milestone release PR reviews: e.g. QualityOnDemand/releases/tag/r1.15 | Comments | Field for exchanging information with RM team, for example: M3: link to review issue #nr - review by RM following review request by Sub Project M4: link to review issue #nr - review by RM following review request by Sub Project M4: selected for approval by TSC M4: OK ReleaseManagement/issues/88 M3: OK ReleaseManagement/issues/73 Any other relevant info | |||||
| Comments | Comments on the API e.g. Previous API version(s) implemented by China Unicom, China Telecom, Vivo (Brazil), Deutsche Telekom (Germany), T-Mobile US, Telefonica (Spain). GSMA certified implementations by China Unicom. (source: https://www.open-gateway.com/operators-map as of 2024-08-16) | |||||||
| Contacts | Contact names for the API release: name1 @name2 |
...