As Bazel continues to evolve in response to your needs, we want to share our 2025 roadmap update.
We plan to bring Bazel 9.0 long term support (LTS) to you in late 2025.
Full transition to Bzlmod
Bzlmod has been the standard external dependency system in Bazel since Bazel 7, replacing the legacy WORKSPACE system. As of March 2025, the Bazel Central Registry hosts more than 650 modules.
With Bazel 9, we will completely remove WORKSPACE functionality, and Bzlmod will be the only way to introduce external dependencies in Bazel. To minimize the migration cost for the community, we'll focus on further improving our migration guide and tool.
Additionally, we aim to implement an improved shared repository cache (see #12227) with garbage collection, and may backport it to Bazel 8. The Bazel Central Registry will also support verifying SLSA attestations.
Migration of Android, C++, Java, Python, and Proto rules
With Bazel 8, we have migrated support for Android, Java, Python, and Proto rules out of the Bazel codebase into Starlark rules in their corresponding repositories. To ease the migration, we implemented the autoload features in Bazel, which can be controlled with --incompatible_autoload_externally and --incompatible_disable_autoloads_in_main_repo flags.
With Bazel 9, we aim to disable autoloads by default and require every project to explicitly load required rules in BUILD files.
We will rewrite most of C++ language support to Starlark, detach it from Bazel binary and move it into the /rules_cc repository. This is the last remaining major language support that is still part of Bazel.
We're also porting unit tests for C++, Java, and Proto rules to Starlark, moving them to repositories next to the implementation to increase velocity of rule authors.
Starlark improvements
Bazel will have the ability to evaluate symbolic macros lazily. This means that a symbolic macro won't run if the targets it declares are not requested, improving performance for very large packages.
Starlark will have an experimental type system, similar to Python's type annotations. We expect the type system to stabilize after Bazel 9 is launched.
Configurability
Our main focus is reducing the cost and confusion of build flags.
We're experimenting with a
new project configuration model that doesn't make users have to know which build
and test flags to set where. So $ bazel test //foo automatically sets the
right flags based on foo's project's policy. This will likely remain
experimental in 9.0 but guiding feedback is welcome.
Flag scoping lets you strip out Starlark flags when they leave project boundaries, so they don't break caching on transitive dependencies that don't need them. This makes builds that use transitions cheaper and faster. Here's an example. We're extending the idea to control which flags propagate to exec configurations and are considering even more flexible support like custom Starlark to determine which dependency edges should propagate flags.
We're up-prioritizing effort to move built-in language flags out of Bazel and into Starlark, where they can live with related rule definitions.
Remote execution improvements
We plan to add support for asynchronous execution, speeding up remote execution by increasing parallelism.
To follow updates to the roadmap and discuss planned features, join the community Slack server at slack.bazel.build.
This roadmap is intended to help inform the community about the team's intentions for Bazel 9.0. Priorities are subject to change in response to developer and customer feedback, or to new market opportunities.