Versions Compared

Old Version 42

changes.mady.by.user Tanja de Groot

Saved on

compared with

New Version Current

changes.mady.by.user Tanja de Groot

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

CAMARA release management process requires each API Sub Project to plan and track their API releases so that meta-release can be planned.

API release tracking consists in 2 steps:

...

Create an API release tracking page (see details below). This needs to be done only once for each API of an API Sub Project.

...

The CAMARA release process uses API release trackers to provide visibility on the status of API versions.

For each public API version planned to be released as part of a meta-release, the API Sub Project shall create an API release tracker. The tracker is used for the planning and shows the progress 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 for each stepon how to support the release process.

Table of Contents

...

API release tracking (umbrella page

...

Each API Sub Project needs to track the release planning for its APIs.

...

)

The API release tracking page is the place where an API Sub Project documents the releases of a given API. One such page is created once for each API of the Sub Project. It is an umbrella page under which all API release trackers will be hosted.

For each API managed in the API Sub Project, the API release tracking page for that API is to be created under the API Sub Project wiki home page. This is done as follows:

...

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, while an API release tracker is dedicated to 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. 

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 name (i.e. the API name is as it appears in the API URL as defined here: API name definition).

Examples

The following are examples of API Sub Projects with their release tracking pages(s) and sample API release trackers:

...

  • actual API Sub Project name.

Create an API release tracker

...

For each new release of an API (e.g. at M0)API, when a public version is planned, a dedicated API release tracker (page) is created to plan and track the progress of that API through the release process. This can be done starting at M0.

To create an API release tracker, go to the your API Sub project's release tracking page (as created per see above section) and do the following:

  • Push the "Add API release tracker" button to create the tracker page for the new API

    release

    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

    1

    v1.0.0

  • Complete the table on the page following the indications in the table below. PLEASE DO NOT CHANGE THE FIRST COLUMN.

  • Add

    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

    release

    version through the release

    cycle.

The second part of the API release tracker page is the API readiness checklist that indicates the relevant release assets that need to be are created for the release.

  • The API readiness checklist needs to be completed for each release, latest at M3 and M4 dates.

...

  • 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.

NOTE: The API release tracker is a normal confluence page (created from a template), and can be edited as such.

API release tracker content explanation

Each API release tracker has the below table that serves as the source for tracking API release progressprogress of the release of the API version.

In particular, this content is pulled into the meta-release planning page (based on the page meta-release label).

title
Info

IMPORTANT

The left column of this table shall not be changedTHE 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 tracker pagestrackers.

Explanations:

Meta-release

The name of the meta-release, e.g

. Fall24

. 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.

See

For the definition of "API name" on this page see: API Release Process, e.g. geofencing

Group

The name of the GitHub repository for the API Sub Project, e.g. DeviceLocation RepositoryThe 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

Target scopeThe shortened link to a GitHub issue called "Scope for target version" which needs to be created latest at M1 and resolved by M3 e.g. DeviceLocation/issues/58Target maturity

, 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 / stable

"initial" or "stable".

Readiness checklist

Scope

The shortened link to

the API readiness checklist for the API. The template of the checklist can be found here: (link to release management repo tbd)M3 dateThe date when the first release-candidate API version is ready. This is the starting point for creating the final release-candidate API version for M4. After this date, only bug fixes and necessary non-breaking changes can be made to the API. Format is yyyy-mm-ddM4 dateThe date when 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 team, the Release Management team can check the release-candidate API version for acceptance and submit to the TSC for approval. Format is yyyy-mm-dd

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

or

, release-candidate or public release) API version. This field is to be updated

at M3 and M4

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.)

pre-release tagThe shortened release tag of the latest pre-release (alpha or release-candidate) for

M3 date

This is the actual date of the M3 pre-release of the API version

e.g. QualityOnDemand/releases/tag/r0.10M5 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

. 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.

 

Public release

The short link to the

PR shall be removed after the commit is done.public-release tagThe shortened release tag of the public-release API version. This field is updated once the public-release has been created, e.g.  QualityOnDemand/releases/tag/r1.0 Comments

Field for exchanging information with RM team, for example 

M3: alpha ready for RM

M3: checked by RM - NOK - missing sunny test cases

M4: ready for RM

M4: ready for approval by TSC

M4: approved by TSC 

M5: public-release done

M5: API version retirement planned by yyyy-mm-dd.

release tag, updated with the 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

API release tracker template v3

This is the baseline NOTE: For Confluence administrators only: the content for the Confluence template is here: Use by RM admins only: Content for API release tracker pages (to be used only by Confluence Admin to copy to the template page).

Start of template:

Add the meta-release label to the page by clicking on the label icon at the top of the page and adding "camara-<meta-release name>", e.g. camara-fall24, camara-spring25, etc.

Remove these lines in red. 

...

Meta-release

...

API name

...

@ name1, @ name2

Additional Information

Add any other useful information about the status of the release heretemplate (v5 - 19/09/2024).