Release process

Major releases

• Decide on a new version number. The first digit should be zero until we decide we're stable enough to be 1.0. The second digit should be incremented (and the third digit set to 0) for releases from master with new features. The third digit should be incremented for bugfix releases (generally these are cherry-picks on top of an older release).
• Ensure that RULES_GO_VERSION in go/def.bzl matches the version you decided on. This can be bumped to a new number any time after a release; it just needs to match when a release is tagged.
• Create a source archive. git archive --output=rules_go-0.6.0.tar.gz master.
  • Note: we create source archives ourselves instead of relying on the GitHub downloads. In the past, changes on the GitHub backend have caused source archives to change so that the sha256 sum no longer matches.
• Create a sha256 sum. sha256sum rules_go-0.6.0.tar.gz | tee rules_go-0.6.0.tar.gz.sha256
• Copy the source archive and sha256 to the bazel-mirror: gsutil cp rules_go-0.6.0.tar.gz rules_go-0.6.0.tar.gz.sha256 gs://bazel-mirror/github.com/bazelbuild/rules_go/releases/download/0.6.0/
• Create a draft of the release notes from the Releases page.
  • The release name and tag should be the version number.
  • The release notes should mention new features and significant bugfixes
  • The release notes should also include WORKSPACE boilerplate and a link to the source archive. Be sure to include the sha256 sum. Make sure urls lists both the GitHub and bazel-mirror copy of the archive.
  • Attach the source archive and sha256 file.
  • Mark the release as "Pre-release".
  • Save a draft; DO NOT publish yet.
• Create a PR to update README.rst.
  • Add an announcement for the new release. Delete old announcements (keep the last three or so).
  • Update any references to the "latest release".
  • Update the Bazel minimum version, if needed.
  • Update the WORKSPACE boilerplate.
• Get the release notes and the README PR approved.
• Publish the release, then merge the README PR. Try to do this close together.
• E-mail the release notes to bazel-go-discuss.

Minor releases

The procedure for minor releases is mostly the same as major releases, with a few important differences.

• Minor releases are tagged from a release branch, not master. The release branch should have a name like release-0.10 and should start at a major release tag (like 0.10.0).
  • Commits are cherry-picked to this branch. Review is only needed if there are significant differences with backporting.
  • Travis CI will test pushes to release branches automatically. Check https://travis-ci.org/bazelbuild/rules_go after you push.
• Release notes should contain a list of bug fixes (not normally included in major releases) and WORKSPACE boilerplate.
• The boilerplate code in README.rst only needs to be updated if this is a release on the latest major branch. An announcement should be added to README.rst in any cases.
• README.rst is updated on the master branch, not on the release branch.