Versions Compared

Old Version 17

changes.mady.by.user Eric Murray

Saved on

compared with

New Version 18

changes.mady.by.user Tanja de Groot

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 docuemntationdocumentation)
      • 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.
      • avoids the use of the word "customer", unless explicitly explained what is meant. Alternative can be (application) end-user, API consumer, etc.
      • avoids reference to CSPs in case also Aggregators, etc. may expose the API. Use e.g. API platform or exposure platform. 
    • presence of the x-camara-commonalities : release referenced, e.g. 0.4.0-rc.1 or 0.4.0.
  • Check servers object has the correct version format e.g. v0.xrc1 or v1rc1, v1rc1, v0.x or v1.
  • 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 field is optional, but recommend to point to the CAMARA, repo.
      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 - 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.

...