CAMARA release management process requires each API Sub-project to plan and track their API releases so that meta-release can be planned.
...
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 link to GitHub repository for the API Sub-project, e.g. https://github.com/camaraproject/DeviceLocation |
| Target version | The API version that you plan to publish in the indicated meta-release, e.g. 1.0.0 |
| Target scope | The link to a GitHub issue called "Scope for target version" which needs to be created latest at M1 and resolved by M3 |
| Target maturity | Indicates the maturity of the API version that is targeted in the upcoming meta-release: choose one of initial / stable. |
| M3 date | The 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 date | The 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 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 release tag of the latest pre-release (alpha or release-candidate) for the API version e.g. https://github.com/camaraproject/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 release tag of the public-release API version. This field is updated once the public-release has been created, e.g. https://github.com/camaraproject/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 |
...
| Page Properties | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Nr | API release assets | alpha | release-candidate | public-release | |||
initial | stable | ||||||
1 | API definition |
|
|
|
| ||
2 | Application of design Design guidelines from Commonalities followed | N |
|
|
| ||
3 | Application of profile Profile guidelines from ICM followed | N |
|
|
| ||
| 4 | API versioning conventions followed |
|
|
|
| ||
| 5 | API release numbering conventions followedLinting rules enabled |
|
|
|
| ||
6 | Linting rules enabledAPI documentation |
|
|
|
| ||
7 | Security reviewUser stories |
|
|
|
| ||
8 | Protected branches enabled | Sunny day API test cases and documentation | N |
|
|
| |
9 | Full set of API test cases and documentation |
N |
N |
|
| ||
10 | Maintainers doc (from at least 3 distinct companies) |
| Test results (API test cases passed) | N | Y |
|
|
11 | Codeowners doc (from at least 3 distinct companies)Security review |
|
|
|
| ||
12 | Release notes according to templateMaintainers doc (from at least 3 distinct companies) |
|
|
|
| ||
13 | User storiesCodeowners doc (from at least 3 distinct companies) |
|
|
|
| ||
14a | Sunny day API test cases and documentation | NAPI release numbering conventions followed |
|
|
|
| |
14b | Full set of API test cases and documentation | N | NRelease notes according to template |
|
|
|
|
| 15 | Test results (API test cases passed) | N | Protected branches enabled |
|
|
|
|
16 | Release-candidate API version tested in at least 2 operator implementations | N | N |
|
| ||
17 | initial public-release API version certified and launched in at least 2 operators is needed to become stable | N | N | N |
| ||
...