This page tracks the Collected issues from https://github.com/camaraproject/ReleaseManagement/issues/9 and provides the team to look at the overall take from the various threads within the issues, along with a list of items that must be addressed to resolve the relevant issue.
Issues | References | Comments | |
1 | API Versioning (Alpha/Beta vs Semantic...) | Consider including Alpha and Beta labels to API versions #13 | 2024-05-13 (tdg) Decoupled release name/number (rx.y) from API version numbering - see API Release Numbering 2024-04-12 (tdg) Decoupling release name/number (rx.y) from API version numbering - see Multiple APIs in one Sub-project 2024-03-27 (tdg): use of alpha API versions for rapid development and release-candidate API versions. No use of beta API versions. These version extensions are only used inside CAMARA, not in API versions part of a meta-release. API versions that have been release as part of a meta-release shall follow the major.minor.patch interpretation of semver 2.0 - see Release management & versioning - proposal - CAMARA Project - Confluence 2024-03-05: Take: |
API Versioning - Aggregation #14 | 2024-03-27 (tdg): use of minor versions in URL only for API versions with x=0. - see Release management & versioning - proposal - CAMARA Project - Confluence. Proposal: A page will be added to the CAMARA Wiki where a CSP can indicate which public-release API versions they support. In addition, CSP shall interact with the channel partner on the lifecycle of their API versions and the maintenance of a given API version. 2024-03-05: Take: | ||
2 | API Family versioning | How to manage version for a API family release #12 | 2024-03-27: API families shall not be version managed only APIs. See: Release management & versioning - proposal - CAMARA Project - Confluence. Existing RM issue #7: Proposal to establish API Families as Working Groups across API Sub Projects #7 opened on Nov 14, 2023 by hdamker. Proposed text to add to this issue: decide on one of the following choices:
2024-03-05: Take: 1. Some contributors express discomfort and confusion with using numerical versions for family releases, especially when API versions are also involved. |
3 | Release Branches | Development and Release Branches #10 | 2024-03-27: See the proposal here: Release management & versioning - proposal - CAMARA Project - Confluence. API can do minor and patched on a maintenance branch. New open issue is on how to handle the alpha API version: tag, branch, other: see: Multiple APIs in one Sub-project 2024-03-05: Take: Input: Problem identified is about Main and Release Branches - that the Camara Versioning Guidelines Doc did not expliciityly specify on which branch development is done. Reporter proponed 2 options. |
4 | API Release 1.0 and general conformance | Readiness Checklist step 6 update proposal #16 | 2024-03-27: See the proposal here: Release management & versioning - proposal - CAMARA Project - Confluence. |
Define mandatory end points URL in each project #11 | 2024-03-27: See the proposal here: Release management & versioning - proposal - CAMARA Project - Confluence. make smaller atomic APIs are recommended. | ||
5 | Add guidance for Info object in apis #15 CLOSED in RM | 2024-05-14: the below was put in issue #15 which will be transferred to Commonalities. Proposed content for the Info field of the API definitions. To be put in the issues list as a follow-up on listed issue #13 and then request for comments. This should be added to the API guidelines document in the Commonalities WG. - needs a PR to be done ---- proposal with some open options ---- title: <human readable API name> without “API” in it, e.g. "Number Verification" description: <text explaining the API, part of the API documentation> e.g. "This API allows to verify that the provided **mobile phone number** is the one used in the device. It verifies that the user is using a device with the same *mobile phone number* as it is declared. ..." - this should include a section on the authentication version: 1.0.1 - Aligned to SemVer 2.0 according to CAMARA design guidelines termsOfService: http://example.com/terms/ - to be replaced by the provider's terms contact: name: <API provider contact name> - check if we can put variables here url: <API provider url> email: <API provider contact name> license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html I checked: variabled seem to be used only in servers object. Add both to API Guidelines and to the Common example file info: title: Number Verification description: | This API allows to verify that the provided **mobile phone number** is the one used in the device. It verifies that the user is using a device with the same *mobile phone number* as it is declared version: 0.2-alpha.1 termsOfService: http://example.com/terms/ contact: name: API Support url: http://www.example.com/support email: support@example.com license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html | |
6 | Automate API design tests to ensure CAMARA compliance #6 | ||
7 | Camara-wide release | No issues |
TODO list
- The current camara_info_version_format rule needs to be created/updated. issue to be put in Commonalities WG.