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 processtrackers.
- 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". The “release PR” provides only the following changes:
- update the version information in the API OAS definition files (no "wip" in any of the API files).
- update of the <API name>-API-Readiness-Checklist.md ensuring al all required release assets are available.
- update of the Changelog.md in the repository with new content on the top for each changed API:
- for an alpha API version, the delta to the previous release
- for the first release-candidate, all changes since the last public-release
- for the subsequent release-candidate, only the delta to the previous release candidate
- for the public-release, the consolidated changes since the last public-release
- the update of the README.md (if as necessary)
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 as defined in the above section on API release numbering.
- Outside the API Sub Project, the release name shall be the API name (for definition see versioning section in the API Design Guidelines) combined with the release number e.g. qod rx.y
Repeat step 3, 4 and 5 for
- alpha releases up to the M3 milestone: rx.1 through rx.m (with first alpha release: r0.1)
- release-candidates between the M3 and the M4 milestone: rx.m+1 through rx.n
- finishing with the public-release for inclusion in the meta-release: rx.n+1
- maintenance-releases (for MINOR and PATCH updates) after public release: rx.n+2 and up
- next release (for MAJOR updates): same as above, starting at rx+1.0
Example moved back to Confluence