Skip to content

Commit

Permalink
Merge pull request #120 from nokia/Updates-of-RM-release
Browse files Browse the repository at this point in the history
Updates of RM release
  • Loading branch information
tanjadegroot authored Nov 14, 2024
2 parents 57e2f78 + 78377c6 commit 25d263f
Show file tree
Hide file tree
Showing 2 changed files with 9 additions and 8 deletions.
14 changes: 7 additions & 7 deletions documentation/API-Readiness-Checklist.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,24 +4,24 @@ Checklist for api-name api-version in rx.y.

| Nr | API release assets | alpha | release-candidate | initial<br>public | stable<br> 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.

Expand Down
3 changes: 2 additions & 1 deletion documentation/API_Release_Guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Expand Down

0 comments on commit 25d263f

Please sign in to comment.