随着 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 的意向。优先级可能会根据开发者和客户反馈或新的市场机遇而发生变化。