The following sections provide guideance on how to review a release PR / issue
API Definition files (YAML) (check version in info & servers objects)
- Check Info object
- version: aligned with the released API version and formatted correctly (per Commonalities)
- description:
- contains sufficient in-line API documentation
- does not use Telco Jargon / abbreviations
- contains the section on auth from ICM
- presence of the x-camara-commonalities: 0.4.0
- Check servers object has the correct version format e.g. v0.xrc1 or v1rc1
- what about checks on security schemes ?
- is there a way to know of an API requires consent request ?
test file(s) availability
- do we need this item - is a duplicate as it is an item in the readiness checklist ?
changelog updated
- Comment: For capturing changes, its is recommended to use the GitHub release feature to get the list of all the changes which can then be selected as appropriate and put in the right categorie (added, changed etc) - ask a GitHub expert how to do this by creating a draft release (guidelines are WIP).
readme updated (enforce correct release number / API version naming)
API readiness checklist(s)
- API definition files
- commonalities
- availability of linting report
- ICM
- versioning (checked in yaml)
- documentation (beyond in-line)
- check for Telco jargon / abbeviations
- user stories
- basic test files (for M3)
- enhanced test files (for M4)
- release numbering
- changelog
- certification - for stable public APIs
General comments:
- if you see a release PR that is nearly ready, add a comment as follows: "Please add @release-management_maintainers to this PR once the PR is ready"