Skip to content

Release process

Jump to bottom
Zhongpeng Lin edited this page Sep 14, 2022 · 11 revisions

Minor releases

The process for creating a Gazelle minor release is unfortunately much more manual than 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 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.
  • 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.
    • Update go.mod with go mod tidy -go=1.17 -compat=1.16 (choosing the latest and previous minor versions).
    • Be careful about using new language and standard library features. This is the only thing that really forces an update for users.
    • 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.
  • Update dependencies.
    • go get -t -u ./...
    • go mod tidy -compat=1.16 (replace 1.16 with the minimum version that Gazelle developers might use).
    • 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.
      • Use search and replace to add _maybe wrapping from tmp.bzl, paste into deps.bzl. Example
      • Use regexp to generate # gazelle:repository directives, paste into WORKSPACE. Example
      • You'll likely need to 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
  • Send PRs for all the above, make sure everything is passing, merge to master.

Gazelle maintainers only:

  • Pull latest master locally
  • Run git archive --output=bazel-gazelle-<version>.tar.gz HEAD to create a release archive.
  • Create a new release from https://github.com/bazelbuild/bazel-gazelle/releases/new
  • Populate release title and notes, upload the release archive and publish it.
  • Update the README to update the code snippet using the newly created release
Clone this wiki locally