Release Cutting


  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.

See FAB-4379 for a template JIRA

Proposals

Weekly release cadence - CBF

  • begin merge moratorium on Weds am at 8 am ET
  • ensure Daily and Weekly tests are run, force repeated CR CI passes of each repository
  • if significant issues found, defer release for following week (no sense killing ourselves)
  • if no significant issues found, proceed with release
    1. create Task for weekly release, cloned from this JIRA Task
    2. assign a release manager to the execution (should not try to coordinate steps, this is where errors of mis-communication occur)
    3. begin the release process at 8am Thursdays
    4. on successful testing of download/images/docs review and e2e testing, spam announce email
  • lift merge moratorium

Notes/Observations

  • combining the fabric and fabric-ca release notes, changelog and makefile changes into a single release CR would simplify things, but means that any CRs that get merged after the release CR is created would require that the changelog be amended accordingly before the release CR is merged.
  • it is critical to rebase the release CR just before it is merged to ensure it picks up latest commits
  • get the release process for java SDK release sorted out. pom.xml and src/test/fixture/sdkintegration/.env need to be updated
  • there was confusion over tag creation, some thought that tags had to be pushed directly to GH, bypassing Gerrit. The way to tag is to create the tag locally and push to Gerrit.
    e.g. git push origin v1.0.0-beta HEAD:refs/heads/master
  • markdown in tag annotations does not work, need to research how other projects manage to get markup into their release notes on GH
  • despite asking people to inspect things, seems like they always find things after the process has begun
  • having the publishing of images tied to the tag is problematic... you can delete a tag locally, but you really cannot once it is in circulation. We really need to be able to test the published images and binaries BEFORE we tag the release so that IFF there are errors, we can remediate and republish, test and then tag.
  • we need a means of driving CI multiple iterations on the current commit level to make us aware of any CI flakiness
  • we should be able to version the examples independently of the release - suggest a separate fabric-samples repository for everything under examples. This would allow the download of the example as git
  • No labels