为了满足您的需求，Bazel 将不断发展，我们想分享一下 2025 年路线图更新。
我们计划于 2025 年底为您提供 Bazel 9.0 长期支持 (LTS)。
全面过渡到 Bzlmod
从 Bazel 7 开始，Bzlmod 已成为 Bazel 中的标准外部依赖项系统，取代了旧版 WORKSPACE 系统。截至 2025 年 3 月，Bazel 中央注册库托管了 650 多个模块。
在 Bazel 9 中，我们将彻底移除 WORKSPACE 功能，并且 Bzlmod 将成为在 Bazel 中引入外部依赖项的唯一方式。为了最大限度地降低社区的迁移费用，我们将专注于进一步改进迁移指南和工具。
此外，我们还计划实现带有垃圾回收功能的改进型共享代码库缓存（请参阅 #12227），并可能将其向后移植到 Bazel 8。Bazel Central Registry 也将支持验证 SLSA 证明。
迁移 Android、C++、Java、Python 和 Proto 规则
在 Bazel 8 中，我们将对 Android、Java、Python 和 Proto 规则的支持从 Bazel 代码库迁移到了相应代码库中的 Starlark 规则。为简化迁移，我们在 Bazel 中实现了自动加载功能，可通过 --incompatible_autoload_externally 和 --incompatible_disable_autoloads_in_main_repo 标志进行控制。
在 Bazel 9 中，我们旨在默认停用自动加载，并要求每个项目在 BUILD 文件中明确加载所需的规则。
我们将将大部分 C++ 语言支持重写为 Starlark，将其从 Bazel 二进制文件中分离出来，并将其移至 /rules_cc 代码库。这是 Bazel 中保留的最后一种主要语言支持。
我们还将 C++、Java 和 Proto 规则的单元测试移植到了 Starlark，并将其移至实现旁边的代码库，以加快规则作者的开发速度。
Starlark 改进
Bazel 将能够延迟评估符号宏。这意味着，如果未请求符号宏声明的目标，则符号宏不会运行，从而提升了超大型软件包的性能。
Starlark 将采用实验性类型系统，类似于 Python 的类型注解。我们预计类型系统将在 Bazel 9 发布后稳定下来。
可配置性
我们的主要目标是降低 build 标志的费用和混淆。
我们正在试验一种新的项目配置模型，让用户无需知道要在哪里设置哪些 build 和测试标志。因此，$ bazel test //foo 会根据 foo 的项目政策自动设置正确的标志。在 Android 9.0 中，此功能可能仍处于实验阶段，但我们欢迎您提供指导性反馈。
借助标志作用域，您可以在 Starlark 标志离开项目边界时将其剥离，以免它们破坏对不需要它们的传递依赖项的缓存。这样，使用转场效果的 build 的构建速度会更快，费用也会更低。下面是一个示例。我们将扩展此想法，以控制哪些标志会传播到执行配置，并考虑提供更灵活的支持（例如自定义 Starlark），以确定哪些依赖项边应该传播标志。
我们将优先考虑将内置语言标志从 Bazel 移至 Starlark，以便与相关规则定义共存。
远程执行方面的改进
我们计划添加对异步执行的支持，通过提高并行性来加快远程执行速度。
如需跟踪路线图的更新并讨论计划推出的功能，请加入社区 Slack 服务器 slack.bazel.build。
此路线图旨在帮助社区了解团队对 Bazel 9.0 的计划。我们会根据开发者和客户的反馈或新的市场机遇调整优先事项。