The following sections provide guideance guidance on how to review a release PR / issue
General questions on reveiw preocess:
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)
Maybe we can extend the review issue:Review actions
- Release Tracker updated (not sure if this makes actually sense ... especially as then there is a wrong "M3" date, see https://wiki.camaraproject.org/display/CAM/OTPValidation+API+Release+Tracking as example)
- (current list)
Release actions
- Review comments addressed (by Sub Project)
- Release PR approved (on behalf of Release Management)
- PR merged (by Sub Project codeowner)
- Release created within GitHub (by Sub Project codeowner)
- Release Tracker updated (M3 date = creation date of release?)
API Definition files (YAML) (check version in info & servers objects)
...
- do we need this item - is a duplicate as it is an item in the readiness checklist ?
- 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 test scenarios (tbc if fir basic or enhanced 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).
...
- 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
...