Bazel 版本发布全史：从 CHANGELOG 读懂版本演进、LTS 策略与关键变更

导读

CHANGELOG.md 是 Bazel 开源构建系统最权威的版本发布档案，记录了从 2015 年 9 月首个公开版本 0.1.0 到 2026 年 9 月 rolling 版本 10.0.0-pre 的全部 349 个发布条目。本篇指南以该文件为主体，系统拆解其条目结构（Baseline、Cherry picks、Incompatible changes、New features、Important changes）、梳理各代 LTS 里程碑的定位与关键变更，并结合仓库内发布模型文档（docs/release/index.mdx）讲解 Bazel 的 Rolling/LTS 双轨发布机制。读完本文，你将能够快速定位任意版本的发布说明、评估升级到新版本时的破坏性变更，并准确理解 Bazel 版本号背后的发布策略。

CHANGELOG.md 在仓库中的定位与文件结构

在 Bazel 仓库中，CHANGELOG.md 位于仓库根目录，与 MODULE.bazel、README.md 同级，是 Bazel 版本管理基础设施的核心输出物之一。仓库还围绕版本发布维护了一整套配套文档：

• docs/release/index.mdx —— 官方发布模型（Release Model）说明，定义 Rolling 与 LTS 双轨机制；
• docs/release/rolling.mdx —— rolling 发布版本列表与说明；
• docs/release/backward-compatibility.mdx —— 破坏性变更（breaking changes）政策；
• docs/release/rule-compatibility.mdx —— 规则兼容性承诺；
• docs/versions/index.mdx 及 docs/versions/ 下按版本归档的文档快照（7.6.1、7.7.1、8.0.1、8.1.1、8.2.1、8.3.1、8.4.2、8.5.1、8.6.0、8.7.0、9.0.0、9.1.0 等），用于对特定大版本提供不随主分支变化的稳定文档。

从数据规模看：CHANGELOG.md 共 25510 行，包含 349 个 ## Release 条目，版本跨度从 0.1.0（2015-09-08）到 10.0.0-pre.20260826.1（2026-09-08），时间跨度约 11 年，是理解 Bazel 演进史的一手资料。

版本条目结构解析：每条 Release 记录了什么

CHANGELOG.md 中的每个版本条目都遵循近乎一致的模板。以最新条目 10.0.0-pre.20260826.1（2026-09-08）为例，其结构包含以下组成部分：

1. 版本号与发布日期

## Release 10.0.0-pre.20260826.1 (2026-09-08)

版本号直接暴露发布轨：带 -pre.YYYYMMDD.N 后缀的是 rolling 预发布版本，纯 major.minor.patch 形式的是正式版本（如 9.2.0、8.8.0）。

2. Baseline（基线提交）

Baseline: 609cb51089a86f7e40552a1f79c16992376f06db

Baseline 指明该版本所对应的源码基线 commit 哈希，是回溯任意版本精确代码状态的锚点，也是后续 Cherry picks 的基准。

3. Cherry picks（精选提交）

Cherry picks:

   + bd75cfcf5c906fb6b88515c993edcd34bfadeecb:
     Update protobuf to 36.0.bcr.1

Cherry picks 列出从主分支或后续提交中精选并回移植入该版本的具体 commit（含哈希与标题）。这是 patch/minor 版本如何获得修复的核心机制，也解释了为什么 LTS 分支可以只携带关键修复而不引入未经验证的功能。

4. 变更分类

每个条目按 Incompatible changes（不兼容变更）、New features（新特性）、Important changes（重要变更）三类组织正文，行内以 - 列表呈现。需要特别留意的是：即便条目中没有显式标注 [Incompatible]，Incompatible changes 段落内的每一项都意味着升级时需要适配。

5. 贡献者致谢

This release contains contributions from many people at Google, as well as Alex Eagle, ...

每个条目末尾列出 Google 之外的社区贡献者名单，体现该版本的社区参与度。

版本号语义与双轨发布模型

要读懂 CHANGELOG，必须先理解 Bazel 的版本命名与发布策略。仓库文档 docs/release/index.mdx 明确说明：

• Bazel 采用 major.minor.patch 的语义化版本（Semantic Versioning）方案：
  • major（大版本）：包含与上一版本不向后兼容的特性，每个 Bazel 大版本都是一个 LTS 发布；
  • minor（次版本）：包含向后兼容的缺陷修复与从主分支回移植的特性；
  • patch（补丁版本）：只包含关键缺陷修复；
  • pre-release（预发布）：在下一个大版本号后附加连字符与日期后缀，例如 7.0.0-pre.20230502.1。

自 Bazel 4.0 起，官方提供两条发布轨：rolling releases（滚动发布） 与 long term support (LTS) releases（长期支持发布）。每个大版本依次经历四个支持阶段：

阶段	含义
Rolling	该大版本仍处于预发布期，Bazel 团队从 HEAD 持续发布 rolling 版本（即 CHANGELOG 中大量 X.0.0-pre.YYYYMMDD.N 条目）
Active	该大版本是当前活跃的 LTS 发布，团队会向其 minor 版本回移植重要特性与缺陷修复
Maintenance	该大版本进入维护模式，团队仅回移植安全与 OS 兼容性相关的关键修复
Deprecated	该大版本停止支持，用户应迁移到更新的 LTS 版本

以 CHANGELOG 实际记录与支持矩阵为准，各代 LTS 的当前状态为：

LTS 版本	状态	最新版本（记录于 CHANGELOG）
Bazel 9	Active	9.2.0（2026-07-13）
Bazel 8	Maintenance	8.8.0（2026-08-31）
Bazel 7	Maintenance	7.7.1（2025-11-12）
Bazel 6	Deprecated	6.6.0（2026-01-21）
Bazel 5	Deprecated	5.x（含 5.4.x 系列维护版本）
Bazel 4	Deprecated	4.2.x 系列维护版本

这一机制在 CHANGELOG 中体现为：每个大版本发布后，其维护 patch（如 8.8.0、9.2.0）与下一个大版本的 rolling 预发布（如 10.0.0-pre.*）会同时持续出现在文件顶部，形成多轨并行推进的格局。

时间线总览：从 0.1.0 到 10.0.0-pre 的 11 年演进

将 CHANGELOG 中的 349 个条目按时间展开，可以梳理出清晰的演进脉络。以下是各阶段的核心里程碑（行号基于仓库根目录的 CHANGELOG.md）：

0.x 时代（2015-09-08 ~ 2019-08）：功能探索与生态构建

• 0.1.0（2015-09-08）是文件中最早的条目，标志着 Bazel 以开源身份对外发布。
• 整个 0.x 系列（0.1.0 ~ 0.29.0，其中 0.29.0 发布于 2019-08-28）持续引入大量 --incompatible_* 前缀的实验性兼容开关，为后续 1.0 固化 API 做准备。这一时期 CHANGELOG 条目以"新增语言规则支持、完善远程缓存、引入 Starlark 原生扩展"为主基调。

1.0 ~ 3.0（2019-10 ~ 2020-04）：稳定化与模块化前夜

• 1.0.0（2019-10-10）标志着 API 进入稳定承诺期。该版本移除了一批已默认开启的兼容开关（如 --incompatible_windows_escape_python_args、--incompatible_use_native_patch），并新增 genrule 的 cmd_bash/cmd_ps/cmd_bat 多平台命令属性、config_setting 多值 flag 匹配、--enable_platform_specific_config 平台化 bazelrc 等特性。
• 2.0.0（2019-12-19）与 3.0.0（2020-04-06）延续每半年左右一个 major 的节奏，持续收紧不兼容变更。

4.0 ~ 6.0（2021-01 ~ 2022-12）：LTS 机制确立与 Bzlmod 前夜

• 4.0.0（2021-01-21）是第一个采用 Rolling/LTS 双轨制的版本（详见 docs/release/index.mdx），此后 CHANGELOG 开始稳定出现大量 X.0.0-pre.YYYYMMDD.N 滚动条目与 LTS 维护条目并存的局面。
• 6.0.0（2022-12-19）作为 Bazel 6 的正式发布，是模块化外部依赖（Bzlmod）从实验走向普及的关键大版本。

7.0（2023-12-11）：默认 Bzlmod 与平台化收尾

7.0.0 条目是文件中最长的单版本发布说明之一，集中呈现了 7.x 时代的几个标志性变化：

• Bzlmod 成为默认外部依赖解析方式，WORKSPACE 走向弃用通道；
• 一批 [Incompatible] 收尾：--incompatible_python_disable_py2 默认开启、--distinct_host_configuration 被移除（自 6.0.0 起即为 no-op）、--experimental_async_execution 变为 no-op、genrule 推荐以 tools 取代 exec_tools；
• 新增 $(rlocationpath) 运行时数据依赖路径展开变量，成为跨平台 runfiles 访问的首选方式；
• cc_shared_library 脱离实验状态；
• 远程缓存新增 --experimental_remote_cache_ttl（默认 3 小时），缓存驱逐时 Bazel 以退出码 39 标识。

8.0（2024-12-09）与 9.0（2026-01-20）：现代 Bazel 双主线

• 8.0.0（2024-12-09）作为 Bazel 8 的 LTS 发布，其后进入 Maintenance 阶段，由 8.4.x、8.5.x、8.6.0、8.7.0、8.8.0（2026-08-31）等维护版本持续提供关键修复。例如 8.8.0 条目记录了对 Windows tw.exe 长 runfiles 路径 Could not chdir 问题的修复。
• 9.0.0（2026-01-20）开启 Bazel 9 时代，其后的 9.1.0（2026-04-20）、9.2.0（2026-07-13）构成 Active 阶段的主要特性回移植版本。

10.0.0-pre 系列（2026 年持续滚动）

文件顶部从 10.0.0-pre.20251217.3（2026-01-13）开始进入 Bazel 10 的 rolling 阶段，到最新 10.0.0-pre.20260826.1（2026-09-08）已累计十余个滚动版本，且每周保持 1~2 次的发布频率，直观展示了 rolling 轨"从 HEAD 持续发布"的工作方式。

最新版本动态：Bazel 10 正在引入什么

截至文件末尾记录的 10.0.0-pre.20260826.1（2026-09-08），最近几个 rolling 条目的内容勾勒出 Bazel 10 的技术方向：

• --rewind_lost_inputs 默认开启：构建在"无需字节（Build without the Bytes, BwoB）"模式下可自动从远程缓存驱逐中恢复——通过回卷（rewind）生成丢失输入的 action 重建产物；磁盘缓存的 action 结果在该模式下也始终被信任。
• Skyframe 变更修剪优化：新增 --experimental_keep_change_prunable_nodes_during_gc 标志，使 Skyframe 在 GC 时保留当前求值未请求、但其依赖经变更修剪后可验证为干净的已计算节点（对应仓库中的 docs/reference/skyframe.mdx 与 docs/reference/skyframe-debugging.mdx 文档体系）。
• Java 运行环境解耦：--server_javabase 与 nojdk 构建的 Bazel 现在除 JDK 外也可使用 JRE。
• 测试交叉编译：测试目标现在可为"没有任何执行平台兼容"的目标平台构建（用于交叉编译场景），运行时的失败由执行期报错代替分析期报错。
• 模块系统健壮性：MODULE.bazel 之间通过 include() 形成的循环依赖现在直接报错而非挂起构建；当根模块改变 use_extension 调用的 dev_dependency 取值时，模块扩展会被正确重跑（扩展可通过 module_ctx.root_module_has_non_dev_dependency 感知）。
• 磁盘缓存效率：支持 copy-on-write 克隆的文件系统上，上传到磁盘缓存的文件以 CoW 方式共享块，降低缓存写入开销。
• C++ 工具链：include 扫描器现在能正确解析构建期生成并随工具链分发的头文件。

更早的 rolling 条目还包含：--experimental_remote_cache_chunking_function（内容定义分块函数选择，支持 auto/fast_cdc_2020/rep_max_cdc）、--downloader_config 重写规则支持 urlencode($1)、BAZEL_LLVM_PROFILE_FILE 环境变量定制 C++ 覆盖率 LLVM profile 文件名模式（默认 %h-%p-%m.profraw）、HTTP 远程缓存对 408/429 状态码的重试等。这些条目共同表明 Bazel 10 的重点是：远程执行与缓存韧性、模块系统正确性、Windows/交叉编译场景补齐。

不兼容变更（Incompatible changes）：升级前必须核对的红线

CHANGELOG 中最具实操价值的段落是每个条目的 Incompatible changes。Bazel 对破坏性变更采取"先以 --incompatible_* 实验开关预告、后默认开启并固化"的渐进策略，而 CHANGELOG 就是追踪这些开关命运的唯一权威索引。

从各代版本中抽取的典型模式：

• 兼容开关翻转：如 --incompatible_python_disable_py2（7.0.0 默认开启）、--incompatible_windows_escape_python_args（1.0.0 移除）。
• 选项移除或改名：如 --distinct_host_configuration（7.0.0 移除）、--experimental_remote_cache_compression 更名为 --remote_cache_compression（7.0.0）、--experimental_remote_build_event_upload 更名为 --remote_build_event_upload 且默认值改为 minimal（7.0.0）。
• 行为语义调整：如 --deleted_packages 多个选项由"后者覆盖"改为"拼接生效"（7.0.0）、.rc 文件中 common 伪命令的语义迁移到新的 always 伪命令（7.0.0）、远程缓存驱逐 blob 时 Bazel 以退出码 39 退出（7.0.0）。
• 跨大版本的行为回退：值得注意的是，10.0.0-pre.20260801.1（2026-08-10）记录了一次罕见的"技术性不兼容变更"——Windows shell 启动器恢复为将 shell 二进制所在目录前置（回到 Bazel 8.x 行为），官方明确说明这是因 9.0.0 中的改动影响面超出预期而回退。这提醒读者：不兼容变更并不总是单向"前进"，CHANGELOG 是确认行为基准的唯一依据。

升级建议：在跨 major 升级前，应完整过一遍 CHANGELOG.md 中目标版本区间内所有条目的 Incompatible changes，并结合 docs/release/backward-compatibility.mdx 中的兼容政策评估影响面。

如何高效检索与利用这份 CHANGELOG

CHANGELOG.md 体量巨大（25510 行），实际使用时建议采用以下检索路径：

1. 确认当前版本与最新版本：查看文件顶部前几行，即最新 rolling 版本；grep -n "^## Release" CHANGELOG.md 可列出全部版本号与行号（本仓库中该命令输出 349 个条目）。
2. 定位某个大版本的正式发布：直接搜索 ## Release X.0.0 ( 即可找到 LTS 里程碑，如 ## Release 8.0.0 (2024-12-09)。
3. 追踪某个 flag 的生命周期：以 flag 名称为关键词搜索整个文件，观察它从实验开关 → 改名 → 默认开启 → 移除的完整轨迹。
4. 核对维护分支的修复内容：定位 X.Y.Z 补丁版本条目，其 Cherry picks 与 Important changes 即该补丁的全部内容。
5. 结合版本归档文档：对于特定大版本，可切换到 docs/versions/ 下的对应版本快照（如 8.6.0、9.1.0），获得与该版本代码同步的稳定文档。

结语

CHANGELOG.md 不只是"变更日志"，它是 Bazel 11 年工程演进的编年史，也是理解 Bazel 发布工程（双轨发布、cherry-pick 回移植、不兼容变更管理）的最佳入口。对于 Bazel 用户而言，熟练阅读这份文件意味着：升级前能准确评估破坏性变更，排查问题时能快速定位行为变更的引入版本，规划迁移时能依据官方支持矩阵做出版本决策。配合仓库中 docs/release/index.mdx、docs/release/rolling.mdx 与 docs/release/backward-compatibility.mdx 等文档，即可构建一套完整的版本管理与升级方法论。