The CAMARA release process requires each API Sub Project to plan and track their API versions so that the meta-release can be planned.
For each target public API version that is planned to be released by an API Sub Project, an API release tracker needs to be created to track its . The tracker is used for the planning and showing the progress of the API version through the release process.
...
A Sub Project's API release tracking page is located under the home page of the API Sub Project. It is automatically created with the API Sub Project page on the wiki.
All API release trackers are located under the release tracking page of the API Sub Project.
...
Go to the following page <API Sub Project name> API Release Tracking, and create a copy indicating your API Sub Project home page as the target parent page.
Replace the <API Sub Project name> in the copied page title with the actual API repository Sub Project name.
Examples
The following are examples of API Sub Projects with their umbrella release tracking page and sample API release trackers:
EXAMPLE: API Sub Project with one API - this example has an API tracing tracking page with trackers for multiple versions of one API
EXAMPLE: API Sub Project with multiple APIs - this example has an API release tracking page with trackers for multiple versions of multiple APIs.
...
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 | ||||||
Target version | The API version that you plan to publish in the meta-release, e.g. 0.5.0, 1.0.0, 1.1.0, etc. Patch Note: patch versions of a released API are handled on the same release tracker as the release API. | Group | The name of the API Sandbox or Sub project under which the repository of the API is managed, e.g. DeviceLocation released API. | ||||
Repository | The shortened short link to GitHub repository for the API, e.g. DeviceLocation | ||||||
Target versionGroup | The API version that you plan to publish in the meta-releasename of the API Sandbox or Sub project under which the repository of the API is managed, e.g. 0.5.0, 1.0.0, 1.1.0, etc. Patch versions are DeviceLocation | ||||||
Maturity level | Indicates the maturity of the public API version that is targeted in the upcoming meta-release: choose one of "initial" or "stable". | ||||||
Scope | The shortened link to a GitHub issue called "Scope for API-name version <x.y.z>" which needs to be created latest at M1 and resolved by M3 e.g. DeviceLocation/issues/58 | ||||||
Readiness checklist |
Edit the macro and put the URL of the API-Readiness-Checklist.md | ||||||
API version | The version of the latest (pre-)release (alpha, release-candidate or public release) API version. This field is to be updated with 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 release | The short link to the release PR when available for review, and once released, the short link to the release tag of the latest pre-release (alpha or release-candidate) for the API version e.g. r1.10. The last pre-release is for the M3 milestone. | ||||||
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 M4 release | The shortened short link to the release PR when available for review, and once released, the shortened short link to the release tag of the latest (pre-)release (alpha or release-candidate or public) for the API version e.g. r1.10. The last pre- release is for the M3 M4 milestone. | ||||||
M4 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 release created between M3 and M4. The last release date is the M4 date of the API. Format is yyyy-mm-dd.M4 release | ||||||
Patch | The shortened short link to the release PR when available for review, and once released, the shortened short link to the release tag of the latest (pre-)maintenance release (release-candidate or public) for the API version e.g. r1.1011. The last release is for the M4 milestone | ||||||
Patch 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 maintenance release created after M5. Format is yyyy-mm-dd. | ||||||
RM review | Review status and short link to the review issue for the M3 and M4 milestone release PR reviews: e.g. 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 |
...