The CAMARA release process requires each API Sub Project to plan and track their API versions so that the meta-release can be planneduses API release trackers to provide visibility on the status of API versions.
For each target public API version planned to be released by an as part of a meta-release, the API Sub Project , shall create an API release tracker needs to be created. The tracker is used for the planning and showing shows the progress of the API version through the release processthroughout its development and release process.
In addition, for APIs that are under development but not yet planned as part of the meta-release, it is highly recommended to create API release trackers as well, so that wide visibility can be provided on those APIs (separately from the meta-release). In this case, the API release tracker’s label shall be changed from “camara-springxx/fallxx” to “camara-other”.
The following sections provide the details on how to support the release process.
| Table of Contents |
|---|
...
API release tracking (umbrella page)
The API release tracking page is the place where an API Sub Project documents the releases of all its API version(s). Note: this page has "tracking" (not "tracker") in its title and there is only one such page per API Sub Project. A , while an API release tracker is dedicated to only target public one specific API version.
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 on the wiki.
All API release trackers are located under the release tracking page of the API Sub Project.
...
Meta-release | The name of the meta-release, e.g. Fall24Springxx or Fallxx. 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. Note: patch versions of a released API are handled on the same release tracker as the released API. | |||||||
Repository | The short link to GitHub repository for the API, e.g. DeviceLocation | |||||||
Group | The name of the API Sandbox or Sub project under which the repository of the API is managed, e.g. DeviceLocation | |||||||
Maturity | 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.mdAPI 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 date | This is the actual date of the M3 pre-release of the API version after approval of its release PR. Update of this field with each pre-release created between M1 and M3. The last is mandatory with the final M3 pre-release creation date is the M3 date of the API. Format is yyyy-mm-dd. | ||||
M4 Pre-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 (release-candidate or public) for the API version e.g. r1.10. The last release is for the M4 milestonetag, updated with each alpha and release-candidate pre-release. | |||||||
M4 date | The date of the release PR availability or the This is the actual date of the M4 public-release of the API version after approval of its release PR. Update of this field with each release created between M3 and M4. The last release date is the M4 date of the APIis mandatory with the final M4 public-release creation date. Format is yyyy-mm-dd. | |||||||
PatchPublic 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 maintenance release (public) for the API version e.g. r1.11tag, updated with the M4 public release and with every public maintenance release. | |||||||
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 M5of a maintenance release (after M4). Format is yyyy-mm-dd. | |||||||
RM reviewreviews | 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 reviews or 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 |
...