You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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

General questions on review process:

Questions to be answered for our process:

  • Who can approve the release PR (the assignee of the review issues)?
  • When do we close the review issue (not before the release is correctly done i would supposed)

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 if an API requires consent request ? where is that documented ? in the description in the Info object ? Is there a guidelines in ICM ?
  • In externalDocs: Should we recommend pointing to just CAMARA, to the individua project or either is fine ?
      description: Project documentation at CAMARA
      url: https://github.com/camaraproject/

test file(s) availability

  • do we need this item - is a duplicate as it is an item in the readiness  checklist ?
  • should the test file contain the version number ? e.g. Feature: CAMARA Call Fowarwing Signal  API, v0.1.0 - Operation call-forwardings - is it required to include the version (as people forget to update it). As the tests are in the same release package, can the version number be avoided in the test features ?
  • all error codes shall be covered by final test scenarios. what do we consider the main error cases for rc ? 
  • can we automate checking that all API spec errors/cases are covered by the tests ?

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 in release issue (tbc)
  • ICM
  • versioning (checked in yaml)
  • documentation (beyond in-line)
    • check for Telco jargon / abbeviations
  • user stories
  • basic test files (for M3)
    • is it necessary for a Feature to reference the API version ? as it is anyway in the same release package ? 
    • cover 200 response and all error responses (tbc)
  • enhanced test files (for M4)
    • all all error responses shall be covered by M4 
    • add guideline to use error codes in scenario names ?
  • 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"
  • for final approval use a comment: "LGTM from ReleaseManagement view."


  • No labels