CAMARA release management process requires each API Sub -project 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 -projectProject.
Create an API release tracker for a given API version that is planned to be released.
...
Create an API release tracking page
Each API Sub -project Project needs to track the release planning for its APIs.
An API release tracking page is the place where an API Sub -project Project documents the releases of a given API. One such page is created once for each API of the Sub -projectProject. It is an umbrella page under which all API release trackers will be hosted.
For each API managed in the API Sub -projectProject, the API release tracking page for that API is to be created under the API Sub -project Project wiki home page. This is done as follows:
- Copy the following page <API name> API release tracking, indicating your API Sub -project 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).
...
The following are examples of API Sub -projects Projects with their release tracking pages(s) and sample API release trackers:
- EXAMPLE: API Sub -project Project with one API
- EXAMPLE: API Sub -project Project with multiple APIs - this example uses one release tracking page for all 3 APIs
- EXAMPLE: API Sub -project Project with multiple APIs v2 - this example uses a dedicate release tracking page for each API
...
The API release tracker is a normal confluence page. The API Sub -project Project can add any additional information about the release as they see useful.
...
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 | |
| Group | The name of the GitHub repository for the API Sub | -projectProject, e.g. DeviceLocation |
| Repository | The shortened link to GitHub repository for the API Sub -projectProject, e.g. DeviceLocation | |
| Target version | The API version that you plan to publish in the indicated meta-release, e.g. 1.0.0 | |
| Target scope | The 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 maturity | Indicates the maturity of the API version that is targeted in the upcoming meta-release: choose one of initial / stable. | |
| Readiness checklist | 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 date | The 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-dd | |
| M4 date | The 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 | |
| API version | The 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 tag | The 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 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 tag | The 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 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...