Versions Compared

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.

...

  • 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 given API version that is planned to be released.

...

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

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.

Contacts

Contact names for the API release: name1 @name2

...

Page Properties

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

...