Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

DRAFT FOR REVIEW

The Release-Guidelines.md file will be created from the below 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.
  2. Create the API release tracker for the target API version as describer here: API release tracking process.
  3. 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
  4. Once the required stability is reached, create the "release PR" (see details here: CreatethereleasePR

  5. 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: APIreleasenumbering
      • 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:  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 for a non-breaking update of a public-release API version 1.0.0, resulting in a new release with API version 1.1.0:

  • Develop the 1.1.0 update on the main branch. The first PR updates the version to wip, and the URL to contain vwip.
  • Once sufficiently stable, update the new API version to 1.1.0-alpha.1.
  • Several intermediate alpha API versions may be created.
  • Then one or more intermediate release-candidate API versions may be created. 
  • The last release-candidate API version will be proposed for meta-release. 
  • For meta-release approval, create the PR for the new public-release API version 1.1.0.
  • After meta-release approval, create the release for the new public-release API version 1.1.0, with its release tag rx+1.n and release package ("latest")).


  • No labels