Page Comparison

How to create an API release ? 

Getting started

1 DRAFT FOR REVIEW

a .md file will be create after the review.

Releasing an API step by step 

1. 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. All discussions wrt to this release shall be handled through this issue

...

1. .

...

1. Create the API release tracker for the target API version as describer here: API release tracking process.

...

1. 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

...

1. • according to the API-Readiness-Checklist file

...

1. Once the

...

1. required stability is reached

...

1. , create the "release PR

...

Repeat step 3 and 4 with alpha releases up to the M3 milestone and release-candidates from the M3 to the M4 milestone.

Create the release PR

A) To create an API release, first a "release PR" (linked to the associated PR issue) must 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 except the following points.

• The “release PR” provides (only) the following changes:
  • the update of the API version information in the API OAS definition files within the repository
    • no API in the repository shall contain “wip” within the version field in the API OAS definition file
    • at least the version of one API will be changed with respect to the previous release (otherwise there is no sense in having a release)
  • 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. For details, see the explanations on the API readiness checklist below.
  • the update of the Changelog.md in the repository with new content on the top for each changed API:
    • 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 release candidate
    • for the public-release, the consolidated changes since the last public-release
  • the update of the README.md (if necessary)

Manage the release PR approval

• 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 API Sub Project Maintainers + one Release Manager
  • public-releases:
    • by the majority of the API 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: a public-release should have a formal approval, the actual review is done based on the release-candidate versions of the APIs.

Merge the release PR and create release

...

1. " (see details here: API Release Process extract for commonalities

2. 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: API Release Process extract for commonalities
     • 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

Repeat step 3, 4 and 5 for

• • alpha releases up to the M3 milestone
  • release-candidates between the M3 and the M4 milestone,
  • finishing with the public-release for inclusion in the meta-release