diff --git a/documentation/API-Readiness-Checklist.md b/documentation/API-Readiness-Checklist.md index bdd30d3..fbe48f5 100644 --- a/documentation/API-Readiness-Checklist.md +++ b/documentation/API-Readiness-Checklist.md @@ -4,24 +4,24 @@ Checklist for api-name api-version in rx.y. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | | relative link | +| 1 | API definition | M | M | M | M | | [relative link](/code/API_definitions/apiname.yaml) | | 2 | Design guidelines from Commonalities applied | O | M | M | M | | Comm. release nr | | 3 | Guidelines from ICM applied | O | M | M | M | | ICM release nr | | 4 | API versioning convention applied | M | M | M | M | | | -| 5 | API documentation | M | M | M | M | | relative link | -| 6 | User stories | O | O | O | M | | relative link | -| 7 | Basic API test cases & documentation | O | M | M | M | | relative link | -| 8 | Enhanced API test cases & documentation | O | O | O | M | | relative link | +| 5 | API documentation | M | M | M | M | | [relative link](/documentation/API_documentation/apiname-API-Readiness-Checklist.md) | +| 6 | User stories | O | O | O | M | | [relative link](/documentation/API_documentation/apiname-Userstory.md) | +| 7 | Basic API test cases & documentation | O | M | M | M | | [relative link](/code/Test_definitions) | +| 8 | Enhanced API test cases & documentation | O | O | O | M | | [relative link](/code/Test_definitions) | | 9 | Test result statement | O | O | O | M | | issue link | | 10 | API release numbering convention applied | M | M | M | M | | | -| 11 | Change log updated | M | M | M | M | | relative link | +| 11 | Change log updated | M | M | M | M | | [relative link](/CHANGELOG.md) | | 12 | Previous public release was certified | O | O | O | M | | comment | To fill the checklist: - in the line above the table, replace the api-name, api-version and the rx.y by their actual values for the current API version and release. - in the Status column, put "Y" (yes) if the release asset is available or fulfilled in the current release, a "N" (no) or a "tbd". Example use of "tbd" is in case an alpha or release-candidate API version does not yet provide all mandatory assets for the release. - in the Reference information column, provide the relative links (from the API repository home folder) to the release asset once available, the applicable release numbers (not versions) of Commonalities and ICM, and any other relevant links or information. -- For the point 12: The Reference information section shall reference a note to be added under the checklist table that states the certified company(s) as can be found on the following link: [GSMA Open Gateway Portal](https://open-gateway.gsma.com/). +- For the point 12: The Reference information comment shall reference a note (e.g. "see (1)") under the checklist table to be added that states the certified company(s) as can be found on the following link: [GSMA Open Gateway Portal](https://open-gateway.gsma.com/). Note: the checklists of a public API version and of its preceding release-candidate API version can be the same. diff --git a/documentation/API_Release_Guidelines.md b/documentation/API_Release_Guidelines.md index 832945c..3d716e2 100644 --- a/documentation/API_Release_Guidelines.md +++ b/documentation/API_Release_Guidelines.md @@ -136,9 +136,10 @@ A (pre-)release PR provides only the following changes:  * for subsequent release-candidate(s), only the delta to the previous release-candidate * for a public release, the consolidated changes since the previous public release * update of the API repository `README.md` file (as necessary) +* request the review of the release PR by adding the camaraproject/release-management_maintainers to the list of reviewers of the release PR. **Create the release** -* manage the release PR approval with the Release Management team +* check the progress of the release PR approval in the review issue created by the Release Management team * merge the approved release PR * create the release: * an API release is created using the GitHub release feature (a release tag and, optionally, a release package).