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)
...
- 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)
...
- 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)
- 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 of if an API requires consent request ? where is that documented ? in the description in the Info object ? Is there a
test file(s) availability
...