The following sections provide guidance on how to review a release PR / issue.
...
- 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 (non blocking for release if in docuemntation)
- contains the section on auth from ICM - issue to put on ICM backlog - apply for next meta-release to API specs Herbert Damker to check with ICM team.
- presence of the x-camara-commonalities: 0.4.0
- Check servers object has the correct version format e.g. v0.xrc1 or v1rc1
- Check security schemes: check presence and format (OIDC) and scope name format.
- Is there a way to know if an API requires consent request ? No, this is local regulation. It is covered when using the security scheme and the scope rules.
- In externalDocs: this filed field is optional, but recommend to point to the CAMARA, repo.
description: Project documentation at CAMARA
url: https://github.com/camaraproject/<repo>- Tanja de Groot to create a Commonalities backlog issue
- Shall error cases be explained in in-line documentation ? (info.description) It seems yes as per Commonalities/documentation/API-DocumentationTemplate.md - Deprecate the doc and doc shall be inline in OAS spec. @Rafal to updater in Commonalities
...
- 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"
- for final approval use a comment: "LGTM from ReleaseManagement."
Release actions
- Tick task when checked and done.
- Check if further review by TSC / Commonalities / ICM is needed (e.g. for targeted stable APIs), and leave issue open until those reviews are marked as done and OK in the review issue
- When all tasks and complementary reviews are completed, close the review issue with a comment on the overall status of the API.
...