Page Comparison

The following sections provide guidance on how to review a release PR / issue

...

Questions to be answered for our process:

Who can approve the M3 release PR (the assignee of the review issues)? Code Owners after RM approval is noted.
When do we close the review issue (not before the release is correctly done i would supposed). when all 11 tasks are closed

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
what about checks on security schemes ?: presence and format (OIDC) and scope name format
~~is there a way to know if an API requires consent request ? where is that documented ? in the description in the Info object ? Is there a guidelines in ICM ? DONE WITH SEC SCHEMA~~
In externalDocs: Should we recommend pointing to just CAMARA, to the individua individual project or either is fine ? It is optional - now review needed. Commonalities backlog issue.
description: Project documentation at CAMARA
url: https://github.com/camaraproject/<repo>
shall error cases be explained in in-line documentation ? (info.description) It seems yes as per Commonalities/documentation/API-DocumentationTemplate.md - I think we need to update this document a bot.bit. 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 view."

Versions Compared