...
- 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)
- The “release PR” provides (only) the following changes:
- No API in the repository shall have “wip” within the version in the API OAS definition file
- 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 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
- 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 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 every 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.
...