DRAFT FOR REVIEW
...
- the expected (pre-)releases for alpha, release-candidate and public-release API versions need to be provided.
- minimally an initial public-release needs to be provided for the meta-release.
- each (pre-)release must include 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
- 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".
...
- 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 : APIreleasenumberingas defined in the above section on API release numbering.
- Outside the project API Sub Project, the release name shall be the API name (for definition see API versioning#APInameversioning section in the API Design Guidelines) combined with the release number e.g. qod rx.y
...