Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »

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.

  • Create an API release tracker for a release of the API. This needs to be done for each API version that is planned to be released.

The following sections provide the details for each step.

Create an API release tracking page

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

An 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:

  • Copy the following page <API name> API release tracking, indicating your API Sub-project home page as the parent page. 
  • Replace the <API 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:

We can choose which of the last 2 approaches we would recommend. For now the text recommends the second approach: a dedicated release tracking page per API.

Create an API release tracker for an API release

For each new release of an API (e.g. at M0), a dedicated API release tracker (page) is created to plan and track the progress of that API release.

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

  • Push the "Add API release tracker" button to create the tracker page for the new API release.
  • In the page title, put the <API name> and the <Target version> as described in the below table, e.g. geofencing 1.0.0
  • Complete the table on the page following the indications in the table below.
  • 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 through the release cycle.

The second part of the API release tracker page is a copy of the API release checklist that can be used as a guidance for ensuring that all relevant release assets are created for the release.

The following updates can be done to the API release checklist:

  • remove the columns not applicable to the current API version
  • Update the checklist for each available release asset, latest at M3 and M4 dates.

The API release checklist needs to be completed at each milestone before handover of the API version to the Release Management team.

The API release tracker is a normal confluence page. The API Sub-project can add any additional information about the release as they see useful.

API release tracker content

Each API release tracker has the below table that serves as the source for tracking API release progress.

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

IMPORTANT

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

Explanations:

Meta-release

The name of the meta-release, e.g. Fall24

API name

The API name. See the definition of API name on this page: API Release Process, e.g. geofencing
GroupThe 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 versionThe API version that you plan to publish in the indicated meta-release, e.g. 1.0.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/58
Target maturityIndicates the maturity of the API version that is targeted in the upcoming meta-release: choose one of initial / stable.
M3 dateThe date when the latest alpha API version is ready. This is the starting point for creating the 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-dd
M4 dateThe date when the 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
API versionThe version of the latest pre-release (alpha or release-candidate) API version to be updated at M3 and M4 date, e.g. 0.2.0_alpha.3, 0.10.0-rc.2, 0.10.1, 1.0.0-rc.5)
pre-release tagThe shortened release tag of the latest pre-release (alpha or release-candidate) for the API version e.g. QualityOnDemand/releases/tag/r0.10
M5 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. Format is yyyy-mm-dd. 

The 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

Any additional information on the API version, e.g.

M4: API approved by TSC 

API release phase-out planned, retirement date planned, etc. Date format is yyyy-mm-dd.

Contacts

Contact names for the API release


API release tracker template v1

This is the baseline for the Confluence template 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

Fall24

API name

<api-name>
Group<API group name>
Repository<shortened link to API Sub-project repository> 
Target version<major.minor.patch>
Target scope<shortened link to GitHub scope issue>
Target maturityinitial
M3 dateyyyy-mm-dd
M4 dateyyyy-mm-dd
API version<API version from the current OAS file>
pre-release tag<shortened release tag link>
M5 dateyyyy-mm-dd + <link to PR for public-release API version>
public-release tag<shortened release tag link>
Comments


Contacts

@ name1, @ name2

API release checklist

Nr

API release assets

alpha

release-candidate

public-release





initial

stable

1

API definition

  • Y
  • Y
  • Y
  • Y

2

Design guidelines from Commonalities

N

  • Y
  • Y
  • Y

3

Profile guidelines from ICM

N

  • Y
  • Y
  • Y
4

API versioning conventions

  • Y
  • Y
  • Y
  • Y
5

Linting rules enabled

  • Y
  • Y
  • Y
  • Y

6

API documentation

  • Y
  • Y
  • Y
  • Y

7

User stories

  • Y
  • Y
  • Y
  • Y

8

Sunny day API test cases and documentation

N

  • Y
  • Y
  • Y

9

Full set of API test cases and documentation

N

N

  • Y
  • Y

10

Test results (API test cases passed)

N

  • Y
  • Y
  • Y

11

Security review

  • Y
  • Y
  • Y
  • Y

12

Maintainers (from at least 3 distinct companies)

  • Y
  • Y
  • Y
  • Y

13

Codeowners (from at least 3 distinct companies)

  • Y
  • Y
  • Y
  • Y

14a

API release numbering conventions

  • Y
  • Y
  • Y
  • Y

14b

Release notes according to template

  • Y
  • Y
  • Y
  • Y
15

Protected branches enabled

  • Y
  • Y
  • Y
  • Y

16

Release-candidate API version tested in at least 2 operator implementations

N

N

  • Y
  • Y

17

initial public-release API version certified and launched in at least 2 operators is needed to become stable

N

N

N

  • Y

To be part of a meta-release, minimally the initial release assets need to be provided.

Additional Information

Add any other useful information about the status of the release here.



  • No labels