We’re pleased to announce the release of Bazel 9.0! This LTS release is the culmination of some multi-year efforts to lay the groundwork for a healthier Bazel ecosystem, and we’re excited to see these efforts finally land. Read the full release notes for Bazel 9.0.

Highlights

Bzlmod fully replaces WORKSPACE

Back in 2021, we introduced Bzlmod, a package manager for Bazel intended to replace the WORKSPACE system. In the past few years, Bzlmod has gained a lot of traction in the community, and has become the default external dependency management system in Bazel.

In Bazel 8.0, we disabled the legacy WORKSPACE system by default; and in 9.0, we’ve completely removed the code supporting WORKSPACE. This enabled us to clear out age-old tech debt and implement some shiny new features with much greater ease, including a local repo contents cache and an experimental remote repo contents cache (thanks to Fabian Meumertzheim!).

But we know the work isn’t over; migration is hard, and many users are still on the old WORKSPACE system. To help with migration, we’ve developed a Bzlmod migration tool and an agent-driven migration setup. They won’t magically complete the migration for you, but will hopefully help you get started and continue to iterate.

Starlarkification has landed

Bazel started out with many language rulesets built in. These rules were written in Java and used private APIs, whereas custom rulesets were written in Starlark and used a more limited set of public APIs. To remove this inconsistency, further enable custom rulesets with more powerful APIs, and ease maintenance of the various rulesets, we started the Starlarkification effort, with the goal of moving built-in rulesets out of Bazel into their own modules written in Starlark.

In Bazel 8.0, we moved most built-in rules into their own modules; and in 9.0, we’ve completed the migration with the removal of built-in C++ rules into rules_cc. Bazel now ships with a lean core with rich APIs, and all previously built-in language-specific rulesets are now shipped separately and can be updated independently from a Bazel release. (A small number of language-specific flags, actions, and toolchain types remain in Bazel for now.)

In 8.0, we introduced the --incompatible_autoload_externally flag to ease migration. With this flag, previously built-in rulesets that are now external modules could still be used as if they were built-in. In 9.0, this flag is empty by default, which means that all rulesets have to be explicitly loaded from external modules. We will remove this flag in 10.0.

Prebuilt protobuf compiler

A long-standing complaint among Bazel users is the need to frequently rebuild the protobuf compiler for seemingly no reason. In Bazel 9, the version of protobuf used by all Bazel builds will be upgraded to at least version 33.4, which includes support for a prebuilt protobuf compiler. In most cases, users can simply set the --@protobuf//bazel/toolchains:prefer_prebuilt_protoc flag to avoid having to build protoc themselves.

For more information, see the announcement on Protobuf News.

Adopting Bazel 9

As with every major release, Bazel 9 introduces incompatible changes. Most of these have been included in our release notes. However, if you run into any difficulties while upgrading, we encourage you to visit the Bazel 9 migration GitHub discussion to ask for help or contribute your own fixes.

Bazel 6 deprecation

With the launch of Bazel 9, we’ll deprecate Bazel 6 according to our release model. We’ll no longer be backporting fixes for security and OS compatibility issues to 6.x.

Thanks to community member Mike Bland, however, we were able to publish one last minor release (6.6.0) to fix incompatibilities with macOS Tahoe. Thank you, Mike!

What’s next?

There’s plenty to look out for on the horizon:

• A new Bazel documentation site: Community members Alan Mond and Alex Eagle have been working with the Bazel team to set up a new documentation site powered by Mintlify, following Alan’s amazing essay, Bazel Docs: Why It Might Be Time For A Refresh. The site is currently in preview mode at preview.bazel.build; we plan to eventually switch bazel.build to this new website.
• A new web UI for Bazel Central Registry: Community member Paul Johnston has developed a new web UI for the Bazel Central Registry, with a more powerful search, views of modules filtered by language and maintainers, and more. The site is currently in preview mode at bcr.stack.build; we plan to eventually switch registry.bazel.build to this new website. A special shoutout to community member Max Goisser, who created the original web UI for the BCR!
• Starlark typing: Following feedback from the community, we have been designing and implementing a typing system for Starlark, aiming to help ruleset developers manage the growing complexity of Starlark code. We plan to ship this in Bazel 10.0. Follow the progress at #27370.

And finally, a big thank-you to the entire Bazel community for your support. Whether it was filing issues, contributing code, or discussing ideas, every little bit helped to make Bazel 9 possible. We hope you’ll continue to participate and follow along through the usual channels: GitHub Discussions, the Bazel Slack channel, @bazelbuild on X (Twitter), the Bazel blog, and the bazel-discuss mailing list. See you next time!