随着 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 中央注册中心还将支持验证 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 的项目政策自动设置正确的标志。此功能在 9.0 中可能仍处于实验阶段，但我们欢迎您提供指导性反馈。
借助标志范围限定，您可以在 Starlark 标志超出项目边界时将其剥离，这样它们就不会破坏不需要它们的传递依赖项的缓存。这使得使用过渡的 build 成本更低、速度更快。 以下是一个示例。我们正在扩展这一想法，以控制哪些标志会传播到 exec 配置，并且正在考虑提供更灵活的支持，例如使用自定义 Starlark 来确定哪些依赖关系边应传播标志。
我们正在优先开展相关工作，将内置语言标志从 Bazel 移到 Starlark 中，以便它们与相关的规则定义共存。
远程执行改进
我们计划添加对异步执行的支持，通过提高并行性来加快远程执行速度。
如需了解路线图的最新动态并讨论计划中的功能，请加入社区 Slack 服务器 slack.bazel.build。
此路线图旨在帮助社区了解团队对 Bazel 9.0 的意向。我们会根据开发者和客户的反馈或新的市场机遇来调整优先级。