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 that is 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 to track its . The tracker is used for the planning and shows the progress through the of the API version throughout its development and release process.
In addition, for public API versions 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
pageon the wiki.
All API release trackers are located under the release tracking page of the API Sub Project.
Note: If the umbrella release tracking page is missing, either contact the CAMARA Confluence support team, or you can create it manually as follows:
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
API repository 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 page with trackers for multiple versions of one API
- EXAMPLE: API Sub Project with multiple APIs - this example has an release tracking page with trackers for multiple versions of multiple APIs
actual API Sub Project name.
Create an API release tracker
...
To create an API release tracker, go to your API Sub project's release tracking page (see above) and do the following:
Push the "Add API release tracker" button to create the tracker page for the new API version to be released.
In the page title, put the <API name> and a "v" followed by the <Target version> as described in the below table, e.g. geofencing v1.0.0
Complete the table on the page following the indications in the table below. PLEASE DO NOT CHANGE THE FIRST COLUMN.
If planned for meta-release, add the meta-release label to the page (e.g. camara-fall24)
Maintain the page up-to-date to reflect the progress of the API version through the release process, e.g. at its various alpha, release-candidate and public version.
The API Sub Project can add any additional information about the API version on its release tracker. as they see useful.
...
In particular, this content is pulled into the meta-release planning page (based on the page meta-release label).
| Info | |
|---|---|
| title | IMPORTANTTHE LEFT COLUMN OF THIS TABLE SHALL NOT BE CHANGED. If you want to add a new field, please contact the release management team through the mailing list to request the addition of the field and the reason to add it. Adding a field will require a manual update to ALL release trackers. |
Explanations:
Meta-release | The name of the meta-release, e.g. |
Springxx 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 | |
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.) |
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-releaseM3 date | This is the actual date of the M3 pre-release of the API version. Update of this field is mandatory with the final M3 pre-release creation date. Format is yyyy-mm-dd. |
Pre-release | The short link to the release tag, updated with each alpha and release-candidate pre-release. |
M4 date | This is the actual date of the M4 public-release of the API version. Update of this field is mandatory with the final M4 public-release creation date. Format is yyyy-mm-dd. |
The link to the PR shall be removed after the commit is done.
Public release | The short link to the release tag |
, updated with the |
Field for exchanging information with RM team, for example
M1: Commonalities/ICM release-candidate ready for approval / approval by TSC
M2: Commonalities/ICM public version ready for approval / approved by TSC
M3: release PR ready for RM review - link to release PR #nr - link to review issue #nr
M3: reviewed by RM - OK /NOK
M4: release PR ready for RM review - link to release PR #nr - link to review issue #nr
M4: reviewed by RM - OK/NOK
M4: selected for approval by TSC - TSC approval: OK/NOK
M5: meta-release closed
M5: API version retirement planned by yyyy-mm-dd.M4 public release and with every public maintenance release. | |
Patch date | The date of the availability of a maintenance release (after M4). Format is yyyy-mm-dd. |
RM reviews | 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 |
NOTE: For Confluence administrators only: the content for the Confluence template is here: Use by RM admins only: Content for API release tracker template (v4v5 - 19/09/2024).