DRAFT FOR REVIEW
...
- the expected alpha, release-candidates and public-release API versions need to be (pre-)released
- minimally an initial public-release need to be provided
- each (pre-)release must provide the required set of API release assets according to the API readiness checklist described below.
- API (pre-)releases are numbered (tagged) using the API release numbering guideline (see below)
Technically, an API release is created using GitHub features:
- A GitHub issue for the release
- A "release PR" for this issue
- If required, a GitHub release package (zip file of the API Sub Project repository)
- A GitHub release tag with the release name rx.y
API release numbering
API release numbers are GitHub tags of the format "rx.y".
...
Releasing an API step by step
This section gives the overview of the steps to release an API. more details can be found in the API Release Process description.
- Create a GitHub issue defining the scope of the targeted API release. Descriptive information in this issue can be reused in the changelog/release notes.
- Create the API release tracker for the target API version as describer here: API release tracking process.
- On the main branch, develop the API scope in a "work-in-progress mode" (API version = wip and version in URL is vwip).
- during development and test, make sure to create and record the required release assets according to the API-Readiness-Checklist file
- Once the required stability is reached, create the "release PR" (see details here: CreatethereleasePR
Manage the "release PR" approval, merge the approved "release PR" and create the release
- An API release is created using the GitHub release feature.
- The release name shall be the same as the release tag and shall have the following format: rx.y
- The x.y number shall follow the release numbering scheme: APIreleasenumbering
- Outside the project the release name shall be the API name (for definition see API versioning#APIname) combined with the release number e.g. qod rx.y
...