Release process

• 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 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.
  • Attach the source archive.
  • 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.