Skip to content

Release process

Jump to bottom
Fabian Meumertzheim edited this page Oct 2, 2024 · 11 revisions

Minor releases

The process for creating a Gazelle minor release is unfortunately much more manual than rules_go.

1. Update rules_go

Update the rules_go version to the latest available. This may also be done after any rules_go release. Gazelle serves as a good chunk of code to test.

  • Update io_bazel_rules_go repository in WORKSPACE.
  • Update rules_go version in MODULE.bazel.
  • Update boilerplate in README.rst.
  • Update compatibility table in README.rst if there are changes.
  • Update minimum version in language/go/config.go if Gazelle will generate targets that require a new feature. This is a soft requirement; Gazelle may still work with older versions.

2. Update the Go version.

Most official Go projects support the last two minor releases. The highest minor version of Gazelle can use the highest minor version of Go though, as long as a previous branch is still supported though.

  • Use the latest version in WORKSPACE. This is just the version used for testing; it doesn't force users onto this version.
  • Use the latest version in README.rst boilerplate.
  • Be careful about using new language and standard library features. This is the only thing that really forces an update for users.

3. Run the releaser tool

bazel run //tools/releaser

If you updated a minor version of Go, you need to also pass the new minor version to the releaser, for example:

bazel run //tools/releaser -- -go_version 1.19

The releaser does the following:

  • go get -t -u ./...
  • Run go mod tidy. If -go_version is passed into the releaser, it would also update go.mod with, for example, go mod tidy -go=1.19 -compat=1.18 (choosing the latest and previous minor versions).
  • go mod vendor
  • find vendor -name BUILD.bazel -delete (some dependencies have build files checked in, which breaks some things)
  • Import into WORKSPACE and deps.bzl. Ironically Gazelle is not good at this because of the _maybe wrapping.
    • Temporarily remove # gazelle:repository directives from WORKSPACE. These interfere with the next step.
    • bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro=tmp.bzl%gazelle_dependencies
    • Revert changes to WORKSPACE.
    • Populate go_repository with _maybe wrapping from tmp.bzl into deps.bzl. To do this manually, you need to use search and replace to add _maybe wrapping from tmp.bzl, paste into deps.bzl. Example
    • Generate # gazelle:repository directives to the end of WORKSPACE. To do this manually, use regexp to generate # gazelle:repository directives, paste into WORKSPACE. Example
    • Add back build_naming_convention = "go_default_library" for com_github_bazelbuild_buildtools, both in deps.bzl and in the WORKSPACE directives.
    • bazel run //:gazelle in case anything changed. (This probably shouldn't do anything other than update naming conventions).
  • Update hardcoded proto import resolution tables.
    • bazel build //language/proto:known_imports && cp -f bazel-bin/language/proto/known_imports.go language/proto/known_imports.go
    • bazel build //language/proto:known_proto_imports && cp -f bazel-bin/language/proto/known_proto_imports.go language/proto/known_proto_imports.go
    • bazel build //language/proto:known_go_imports && cp -f bazel-bin/language/proto/known_go_imports.go language/proto/known_go_imports.go
    • Update the standard package list by running bazel build //language/go:std_package_list, then copying the output file into language/go. This is only used when Gazelle is built with the go command. When Gazelle is built with Bazel, this gets generated automatically.

4. Send PRs for all the above

Make sure everything is passing, notify one of maintainers to review.

Gazelle maintainers only:

Clone this wiki locally