Release process

Minor releases (0.X.0)

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

Patch releases (0.X.Y)

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. The branch may be pushed to the origin repo manually.
  • BuildKite will automatically run CI on pushes to branches in the main repo. Confirm that tests pass at https://buildkite.com/bazel/rules-go-golang before proceeding.
• 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 for the latest release branch. An announcement should be added to README.rst in any case.
• README.rst is updated on the master branch, not on the release branch.