Release process

Minor releases (0.X.0)

1. Test the release candidate in Uber's Go monorepo (if you are not a Uber employee, feel free to get help from one of them)
2. Generate a personal access token on GitHub. Remember to give the token permission to write packages.
3. Set the origin of your local repository to [email protected]:bazelbuild/rules_go.git
4. Run the releaser tool on a revision that includes changes the pull request created above:

bazel run //go/tools/releaser -- prepare -rnotes=$rnotes -version=$version -githubtoken=$githubtoken

where $rnotes is the release notes file, $version is the version to prepare (of the form v1.2.4), and $githubtoken is either a GitHub personal access token or the name of a file containing one. If you are not a Google employee, you need to pass -mirror=false.

This command does the following.

• Creates the release branch if it doesn't exist locally. Release branches have names like "release-X.Y" where X and Y are the major and minor version numbers.
• Creates an archive zip file from the tip of the local release branch.
• Creates or updates a draft GitHub release with the given release notes. http_archive boilerplate is generated and appended to the release notes.
• Uploads and attaches the release archive to the GitHub release.

After these steps are completed successfully, the releaser tool should prompt you to check that CI passes on the release branch, then review and publish the GitHub release.

After the release is complete:

• Request mirroring the release archive to mirror.bazel.build by filing a request in Bazel Github Issue
• Add an announcement to the top of README.rst and update WORKSPACE and examples/basic-gazelle/WORKSPACE boilerplate.
• Update Gazelle to use the new version.

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