Releases are cut by GitHub Actions: pushing a tag of the form vX.Y.Z triggers the Release workflow, which creates the GitHub release and then opens a pull request against the Bazel Central Registry.

When a vX.Y.Z tag is pushed:

1. The Release workflow (based on release_ruleset.yaml) checks out the tag.
2. release_prep.sh creates rules_go-vX.Y.Z.zip with git archive from the tag and generates the release notes boilerplate: the MODULE.bazel snippet and the WORKSPACE snippet with the archive's SHA-256 and the latest stable Go version for go_register_toolchains.
3. The workflow publishes the GitHub release with that boilerplate plus an auto-generated "What's Changed" changelog, and attaches the archive together with provenance attestations (*.intoto.jsonl).
4. The Publish to BCR workflow then generates a BCR entry from the .bcr/ templates and opens a pull request against the Bazel Central Registry using the org-level BCR_PUBLISH_TOKEN secret. The version in the BCR entry is derived from the tag; MODULE.bazel in the repo does not need a version bump (Publish to BCR adds a module_dot_bazel_version.patch to the entry).

Minor releases are tagged directly on master; there is no need to create a release branch (one can always be created later if a patch release requires cherry-picks).

1. Test the release candidate in Uber's Go monorepo (if you are not an Uber employee, feel free to get help from one of them).

2. Pick a commit on master that is green on Buildkite.

3. Tag that commit and push the tag:

   git tag v0.X.0 <commit>
   git push origin v0.X.0
   

4. Watch the Release workflow under the repository's Actions tab. Once it finishes, review the GitHub release notes and edit them as needed (e.g. add a highlights section at the top). Editing the notes after publication is fine — the boilerplate and archive are already in place.

5. Verify that the BCR pull request opened by the Publish to BCR workflow passes presubmit and gets merged.

The procedure is mostly the same as for minor releases, with a few differences:

• Patch releases are tagged from a release branch instead of master. If the branch doesn't exist yet, create it from the minor release tag:

  git branch release-0.X v0.X.0
  git push origin release-0.X
  

• Cherry-pick the commits to be released onto the release branch and push it. Review is only needed if there are significant differences with backporting.

• Confirm that Buildkite CI passes on the release branch at https://buildkite.com/bazel/rules-go-golang, then tag its tip as v0.X.Y and push the tag. Everything else happens automatically.

• Release notes should contain a list of bug fixes (not normally included in minor releases). Add them by editing the published GitHub release; the auto-generated changelog covers the cherry-picked PRs.

• If the Release workflow fails, re-run the failed jobs from the Actions tab. The tag does not need to be re-pushed.
• If the release was created but the BCR publication failed, manually dispatch the Publish to BCR workflow from the Actions tab and enter the tag name. This can also be used to re-publish an entry after fixing the .bcr/ templates (see the templates_ref input of the underlying publish-to-bcr workflow).
• Tags are immutable, so if necessary, a new patch version has to be tagged and released when releasing failed.