随着 Bazel 不断发展以满足您的需求，我们希望分享 2025 年路线图更新。
我们计划在 2025 年底为您提供 Bazel 9.0 长期支持 (LTS)。
完全过渡到 Bzlmod
自 Bazel 7 以来，Bzlmod 一直是 Bazel 中的标准 外部依赖项系统，取代了旧版 WORKSPACE 系统。截至 2025 年 3 月，Bazel Central Registry 托管了 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 推出后稳定下来 。
可配置性
我们的主要重点是降低构建标志的成本和减少混淆。
我们正在尝试一种
新的项目配置模型，该模型无需用户知道要在何处设置哪些构建
和测试标志。因此，$ bazel test //foo 会根据 foo 项目的政策自动设置
正确的标志。这在 9.0 中可能仍处于实验阶段，但欢迎提供指导性反馈。
借助标志范围，您可以在 Starlark 标志离开项目边界时将其剥离 ，这样它们就不会破坏 不需要它们的传递依赖项的缓存。这使得使用 转换 的构建更便宜、更快。 下面是一个 示例。我们正在扩展这一想法，以控制哪些标志传播到 exec configurations 并考虑提供更灵活的支持，例如自定义 Starlark 来确定 哪些依赖项边缘应传播标志。
我们正在优先努力将内置语言标志从 Bazel 移至 Starlark，以便它们可以与相关的规则定义共存。
远程执行改进
我们计划添加对异步执行的支持，通过提高并行性来加快远程执行速度。
如需了解路线图的更新并讨论计划的功能，请加入社区 Slack 服务器：slack.bazel.build。
此路线图旨在帮助社区了解团队对 Bazel 9.0 的 意图。优先级可能会根据 开发者和客户反馈或新的市场机会而发生变化。