...
Nr | API release assets | Explanation |
1 | API definition | This is the OAS API definition file (yaml/json per https://spec.openapis.org/oas/v3.0.3). It shall be present in the home/code/API_definition folders of the API Sub-project and validated using the linting rules in point 6. |
2 | Design guidelines from Commonalities applied | This corresponds to a set of linting rules provided by Commonalities that are successfully executed against the OAS API definition file. The output report of the linting shall be provided. Other guidelines that cannot be verified by linting rules should be listed by the Commonalities team team, in particular data type alignment to the Commonalities/artifacts/CAMARA_common.yaml |
3 | Profile guidelines from ICM applied | This corresponds to a set of linting rules provided by ICM that are successfully executed against the OAS API definition file. The output report of the linting shall be provided. |
4 | API versioning conventions applied | This shall be checked through a linting rule added to the Commonalities rule set on the format of the version field in the OAS API definition file. The current camara_info_version_format rule needs to be created/updated. |
5 | API documentation | The API specification should include all the needed documentation. API documentation beyond the embedded in the API definition file, shall be located in the home/documentation/API_documentation folder of the API Sub-project. It shall follow the Commonalities/documentation/API-DocumentationTemplate.md |
6 | User stories | At least 2 User Stories need to be documented by the API Sub-project team and validated by the CAMARA User Council. User Stories shall follow the provided template: Userstory-template.md and be located in the home/documentation/API_documentation folder of the API Sub-project. |
7 | Sunny day API test cases and documentation | At least one Gherkin feature file is provided for the API in the Test_definitions folder of the API Sub-project covering sunny day scenarios. |
8 | Full set of API test cases and documentation | Gherkin feature files are provided for the API in the Test_definitions folder of the API Sub-project covering sunny and rainy day scenarios |
9 | Test results (API test cases passed) | All available Gherkin feature files have been successfully executed against an (which?) API implementation and the test result report is provided. |
10 | Security review | API definition shall include a security scheme section that complies with the AuthN&AuthZ techniques agreed in Commonalities. Can a linting rule be provided ? |
11 | API release numbering conventions applied | This is verified using the information on the release tracker page. |
12 | Release notes according to template | Release notes need to be provided following the template and are located in the . |
13 | Release-candidate API version tested in at least 2 operator implementations | References to at least 2 operator implementations of the API are provided. In which form shall this information be provided ? Links to websites could be added to the API release tracker. |
14 | initial public-release API version certified and launched in at least 2 operators is needed to become stable | References to at least 2 certifications and at least 2 commercial operator implementations of the API are provided. In which form shall this information be provided ? Links to websites could be added to the API release tracker. |
...
Nr | API release assets | alpha | release-candidate | public-release | |
initial | stable | ||||
1 | API definition | Y | Y | Y | Y |
2 | Design guidelines from Commonalities followedapplied | N | Y | Y | Y |
3 | Profile guidelines from ICM followedapplied | N | Y | Y | Y |
4 | API versioning conventions followedapplied | Y | Y | Y | Y |
5 | API documentation | Y | Y | Y | Y |
6 | User stories | Y | Y | Y | Y |
7 | Sunny day API test cases and documentation | N | Y | Y | Y |
8 | Full set of API test cases and documentation | N | N | Y | Y |
9 | Test results (API test cases passed) | N | Y | Y | Y |
10 | Security review | Y | Y | Y | Y |
11 | API release numbering conventions followedapplied | Y | Y | Y | Y |
12 | Release notes according to template | Y | Y | Y | Y |
13 | Release-candidate API version tested in at least 2 operator implementations | N | N | Y | Y |
14 | initial public-release API version certified and launched in at least 2 operators is needed to become stable | N | N | N | Y |
...