Please add your questions to this page.
| Table of Contents |
|---|
...
What are the prerequisites to release a stable
...
version ?
...
- a previous public API version is available at least 1 certified implementation
- all release assets are available as per the API readiness checklist
- there were not too many changes wrt the previous version
- it is expected to not have any breaking changes in the next 2 meta-releases
- the TSC approves it
...
What to do if I accidentally released my API before Release Management check ?
You can easily create a next release rx.y+1 at any time.
In this case, create a "Release Management review" issue in your Sub Project and assign it to a release manager (tanja, samuel, herbert, jose luis, rafal)
If there is a change required, this will be put in the comments in the issue and the Sub Project team can start a new PR to include the changes.
NOTE: If there are substantial change the version should go back to wip in a dedicated PR and release later. If it concerns content changes to the API yaml file, then also the API version should be increased in-line with the type of change (most likely MINOR ot PATCH).
The Sub Project can decide when to merge the PR and create the new release.
What to do in case of codeowner absence (only during holidays) ?
You should have at lease 2 or preferably 3 codeowners
However in case of issues, if consent of the team seems OK, an admin can do a merge (email: adm@camaraproject.org)
HINT: How do I check that links in my Sub Project are defined correctly ?
To check links in the repo, create a (test)branch, tag it with the targeted release tag name.
It will give errors if links are not aligned. Then delete the (test)branch.
Update the links latest in the release PR.
M3: yaml info object: How to add reference to commonalities and remove 'termsOfService' and 'contact' fields ?
In your API yaml file, in the info object, under the version field, please make sure to add: x-camara-commonalities: 0.4.0
`NOTE: the The fields `termsOfService` and `contact` are optional and can shall be removed. They are put by API providers for their implementation if they so desire.
example:
`infoinfo:
title: One Time Password SMS
...
[Camara Security and Interoperability Profile](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md) provides details on how a client requests an access token.
...
x-camara-commonalities: 0.4.0
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
M3: yaml servers object: How to put the API version in the URL ?
The servers object should look like this (API Guidelines section 11.1):
servers:
- url: '{apiRoot}/yourapiname/v0.yrc1' (for initial release or v1rc1 in case of stable release)
variables:
apiRoot:
default: http://localhost:9091
description: API root, defined by the service provider, e.g. `api.example.com` or `api.example.com/somepath`