CAMARA release management process requires each API Sub-project to plan and track their API releases so that meta-release can be planned.
...
The second part of the API release tracker page is the API release readiness checklist that indicates the relevant release assets that need to be are created for the release.
- The API release readiness checklist needs to be completed for completed for each release, latest at M3 and M4 dates.
...
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-project, e.g. DeviceLocation |
| Repository | The 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. 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 latest alpha 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 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 |
Link to API readiness checklist: <link>
API release tracker template v1
...
| Page Properties | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
...
API versioning conventions
...
- Y
...
- Y
...
- Y
...
- Y
...
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
...
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
...
Additional Information
Add any other useful information about the status of the release here.
...