Release process

Minor releases (0.X.0)

1. Update dependencies to their latest release.
2. Decide on a new version number. The first digit should be zero until we decide we're stable enough to be 1.0. The API has been stable for a while, but we should identify any API tech debt that needs to be deleted before committing to long-term stability. 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).
3. Commit a change that sets RULES_GO_VERSION in go/def.bzl and version in MODULE.bazel to the new version. For minor releases, this change should be on the master branch.
4. Send a pull request. (No need to write detailed release notes; Just document the major changes in the PR, or let the maintainers handle it)
5. 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)

For rules_go maintainers only:

1. Review and merge the pull request created in Step 4 above.
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 git@github.com: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.
• Checks that RULES_GO_VERSION is set in go/def.bzl on the local release branch for the minor version being released. RULES_GO_VERSION must be a semantic version without the "v" prefix that Go uses, like "1.2.4". It must match the -version flag, which does require the "v" prefix.
• 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.
• Request mirroring the release archive to mirror.bazel.build by filing a request in Bazel Github Issue

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:

• If you passed -mirror=false to the releaser tool, you need to ask a Google employee in Bazel team to upload the archives for new rules_go and its dependencies versions to mirror.bazel.build by filing an mirror request 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.