Bazel 10.0 Flags Move Toward Migration Testing

What shipped #

Bazel's release stream currently has three overlapping tracks. The Bazel 10.0.0rc1 notes, dated 2026-10-07, describe 10.0 as a major long-term-support release with new features and backward-incompatible changes. The same date marks Bazel 9.3.0, a minor LTS release that the notes describe as fully backward compatible with Bazel 9 releases starting from 9.0.1. Two prereleases came after that: 10.0.0-pre.20261001.2, dated 2026-10-12, and 10.0.0-pre.20261006.3, dated 2026-10-14.

Key facts #

• The 10.0.0rc1 notes list flags flipped in 10.0, including --rewind_lost_inputs, --incompatible_no_implicit_file_export and --incompatible_exclude_starlark_flags_from_exec_config.
• Bazelisk's migrate mode, driven by the BAZELISK_INCOMPATIBLE_FLAGS environment variable, lets teams test those flag flips with Bazel 9.x.
• 9.3.0 enables --rewind_lost_inputs by default, so builds without the bytes can recover from remote cache eviction.
• 9.3.0 adds Label.repo_root and repository_ctx.patch(directory), and reports cycles between MODULE.bazel files linked by include() as errors instead of hanging.
• The 10.0 prereleases add --target_query and --target_query_file, which build or test the result of a query in one command.
• The 2026-10-14 prerelease makes bazel mod tidy evaluate every module extension in the dependency graph, and adds a stdout parameter to ctx.actions.run.

A migration plan, not just a feature list #

The 10.0 candidate reads more like a migration schedule than a feature drop. Flags such as --incompatible_no_implicit_file_export change how existing workspaces resolve files, so breakage shows up in build definitions rather than in compiled code. The notes separate flags that are already flipped in 10.0 from flags that will flip in a future major release, which gives maintainers a list to work through before the default changes arrive. The bazelisk migrate path is the practical part: it lets a team exercise those flips against the 9.x line it already runs, rather than discovering the failures after an upgrade.

The lockfile change deserves the same attention. The 10.0 notes say bazel mod tidy now evaluates all module extensions in the dependency graph, including extensions used only by dependencies. The notes present it as a full replacement for bazel mod deps when the goal is an up-to-date lockfile. They also warn that, when using bazel vendor, this may require vendoring additional dependencies. A command that used to touch a smaller part of the graph can now change what your vendor directory must contain.

Remote execution gets more forgiving #

The remote changes are the most operationally visible part of the 9.3.0 release. Making --rewind_lost_inputs the default means that when a remote cache loses an input, Bazel reruns the action that produced it. The notes also say that disk cache entries removed by a concurrent garbage collection are treated as cache misses rather than failures, and that HTTP remote caching now retries 408 and 429 responses. These changes reduce the cases where a transient cache state fails an otherwise healthy build, although they do not remove the need to size and monitor caches.

Why it matters #

For most teams, the value of this cycle is predictability. A long-term-support line that accepts backward-compatible minor releases lets platform owners schedule upgrades without rewriting build files. The 10.0 candidate then gives a way to see what will break, while the flagged changes still have a known migration path. The repository and query additions also help larger monorepos. Label.repo_root replaces the deprecated Label.workspace_root, and the new query flags let a single command both compute and build a query result.

The release notes also show how Bazel is handling old behavior. The 10.0 candidate removes the deprecated new_git_repository rule, telling users to use git_repository instead, since the notes say they are identical. Its handling of --incompatible_modify_execution_info_additive is another example: the flag is deprecated and a no-op, and multiple --modify_execution_info values are always applied in order.

Who is affected #

Teams running Bazel 9.x should look at 9.3.0 first, because the notes describe it as backward compatible with 9.0.1 and later 9 releases. Its remote-execution default change is the one most likely to alter behavior in a build that uses Build without the Bytes, so those teams should watch the first runs after upgrading. Teams planning for 10.0 should run the flipped flags through bazelisk's migrate mode before they change any defaults. Anyone who vendors dependencies with bazel vendor should review the lockfile change before running bazel mod tidy in CI.

Windows and Android users have specific items. The 2026-10-12 prerelease says Windows parameter files now preserve empty arguments and escape backslashes correctly, and that bazel run --run_under=... --script_path=... escapes batch script invocations correctly on Windows. The 2026-10-14 prerelease adds an implicit dependency on rules_android v0.8.0 through MODULE.tools, which affects projects that build Android targets. Users of bazel query --output=streamed_proto can opt into parallel serialization with --experimental_parallel_streamed_proto_output.