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

Compare with Current View Page History

« Previous Version 2 Current »

  1. Create a release branch, and name it vM.m[.p][-qualifier] where M is the major release identifier, m is minor release identifier, p is the patch level identifier (only for LTS releases) and -qualifier is from the taxonomy of release maturity labels. To create a new branch, navigate to https://gerrit.hyperledger.org/r/#/admin/projects/fabric,branches. You can replace 'fabric' in the URL with the project name.

  2. Create a Change Requests (CR) on the branch, labeled “Release xxx” and update Makefile:IS_RELEASE = true and Makefile:BASE_VERSION=xxx

  3. Create another CR (basically “undo” the release state by the CR above), by setting Makefile:IS_RELEASE=false and Makefile:BASE_VERSION=xxx+1

  4. Once accepted, submit a tag against the $sha of the first CR; the tag triggers Jenkins to build/publish the docker images. Here is an example of when we released v0.6.1-preview CR1 and CR2

  5. Publish release notes in an update to fabric/docs/releases.md.

  6. Announce the release, linking to the release notes on Hyperledger fabric and general slack channels and hyperledger-fabric and hyperledger-announce mailing lists

  7. Perform if necessary:

    1. Select issues to fix for the release branch and label them as such with a label with a value of the release identifier.

    2. Submit change requests for those selected issues against the release branch.

    3. Maintainers decide on whether to merge the requested changes from the release branch to the master branch or requesting the authors to submit the changes on both branches.

  • No labels