Page History

...

To create an API release, a "release PR" (and the associated PR issue before) needs to be created to do a release of the API's repository:

• The “release PR” does not change the content of what is in the repository (either an alpha release, a release-candidate or a public-release API version)except the following points.
• The “release PR” provides (only) the following changes:
  • the version information in the API OAS definition files within the repository where
    • no
    No
    • API in the repository shall
    have
    • left with “wip” within the version in the API OAS definition file
    The
    • at least the version of
    at least
    • one API will be changed (otherwise there is no sense in having a release)
    as follows:
  only
  • the
  delta to the previous release for
  • update of the <API name>-API-Readiness-Checklist.md which confirms the availability of all required release assets as defined for the release type: API Release Process
  • the update of the Changelog.md in the repository with new content on the top:
    • the delta to the previous release for an alpha API version
    • for the first release-candidate
  ,
  • • all changes since the last public-release
    • for the subsequent release-candidate
  ,
  • • only the delta to the previous
  one
  • • release candidate
    • for the public-release
  ,
  • • the consolidated changes since the last public-release
  • the version information in the API OAS definition files within the repository
  • the update of the <API name>-API-Readiness-Checklist.md which confirms the availability of all required release assets as defined for the release type: API Release Process
  • the update of the Changelog.md in the repository
  • the update of the update of the README.md (if necessary)
• A  “release PR” has to be approved before the code owner is allowed to merge as follows:
  • alpha releases: by one other code owner (as for any PR)
  • release-candidates: by the majority of the sub project Maintainers + one Release Manager
  • public-releases:
    • by the majority of the sub project Maintainers (normally given, if the preceding release-candidate was approved), and
    • by the TSC (to be discussed how this will be done formally)
  • NOTE: public-release should have a formal approval, the actual review is done based on the release-candidate versions of the APIs.

...

• Directly after the PR is merged, the release tag will be created with the GitHub release functionality ("Draft/publish a new release")
  • The release description will be copied from the (just merged) CHANGELOG.md (only the new part)
  • For releases with alpha and release candidate version "Set as a pre-release", for public-releases "Set as latest release"

API release numbering

API release numbers are GitHub tags of the format "rx.y".

...