ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

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

Bazel 版本发布全史:从 CHANGELOG 读懂版本演进、LTS 策略与关键变更 Bazel 版本发布全史从 CHANGELOG 读懂版本演进、LTS 策略与关键变更【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel导读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.02015-09-08到10.0.0-pre.20260826.12026-09-08时间跨度约 11 年是理解 Bazel 演进史的一手资料。版本条目结构解析每条 Release 记录了什么CHANGELOG.md 中的每个版本条目都遵循近乎一致的模板。以最新条目10.0.0-pre.20260826.12026-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: 609cb51089a86f7e40552a1f79c16992376f06dbBaseline 指明该版本所对应的源码基线 commit 哈希是回溯任意版本精确代码状态的锚点也是后续 Cherry picks 的基准。3. Cherry picks精选提交Cherry picks: bd75cfcf5c906fb6b88515c993edcd34bfadeecb: Update protobuf to 36.0.bcr.1Cherry 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 版本状态最新版本记录于 CHANGELOGBazel 9Active9.2.02026-07-13Bazel 8Maintenance8.8.02026-08-31Bazel 7Maintenance7.7.12025-11-12Bazel 6Deprecated6.6.02026-01-21Bazel 5Deprecated5.x含 5.4.x 系列维护版本Bazel 4Deprecated4.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.md0.x 时代2015-09-08 ~ 2019-08功能探索与生态构建0.1.02015-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.02019-10 ~ 2020-04稳定化与模块化前夜1.0.02019-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.02019-12-19与3.0.02020-04-06延续每半年左右一个 major 的节奏持续收紧不兼容变更。4.0 ~ 6.02021-01 ~ 2022-12LTS 机制确立与 Bzlmod 前夜4.0.02021-01-21是第一个采用 Rolling/LTS 双轨制的版本详见 docs/release/index.mdx此后 CHANGELOG 开始稳定出现大量X.0.0-pre.YYYYMMDD.N滚动条目与 LTS 维护条目并存的局面。6.0.02022-12-19作为 Bazel 6 的正式发布是模块化外部依赖Bzlmod从实验走向普及的关键大版本。7.02023-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.02024-12-09与 9.02026-01-20现代 Bazel 双主线8.0.02024-12-09作为 Bazel 8 的 LTS 发布其后进入 Maintenance 阶段由8.4.x、8.5.x、8.6.0、8.7.0、8.8.02026-08-31等维护版本持续提供关键修复。例如8.8.0条目记录了对 Windowstw.exe长 runfiles 路径Could not chdir问题的修复。9.0.02026-01-20开启 Bazel 9 时代其后的9.1.02026-04-20、9.2.02026-07-13构成 Active 阶段的主要特性回移植版本。10.0.0-pre 系列2026 年持续滚动文件顶部从10.0.0-pre.20251217.32026-01-13开始进入 Bazel 10 的 rolling 阶段到最新10.0.0-pre.20260826.12026-09-08已累计十余个滚动版本且每周保持 1~2 次的发布频率直观展示了 rolling 轨从 HEAD 持续发布的工作方式。最新版本动态Bazel 10 正在引入什么截至文件末尾记录的10.0.0-pre.20260826.12026-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_py27.0.0 默认开启、--incompatible_windows_escape_python_args1.0.0 移除。选项移除或改名如--distinct_host_configuration7.0.0 移除、--experimental_remote_cache_compression更名为--remote_cache_compression7.0.0、--experimental_remote_build_event_upload更名为--remote_build_event_upload且默认值改为minimal7.0.0。行为语义调整如--deleted_packages多个选项由后者覆盖改为拼接生效7.0.0、.rc文件中common伪命令的语义迁移到新的always伪命令7.0.0、远程缓存驱逐 blob 时 Bazel 以退出码 39 退出7.0.0。跨大版本的行为回退值得注意的是10.0.0-pre.20260801.12026-08-10记录了一次罕见的技术性不兼容变更——Windows shell 启动器恢复为将 shell 二进制所在目录前置回到 Bazel 8.x 行为官方明确说明这是因 9.0.0 中的改动影响面超出预期而回退。这提醒读者不兼容变更并不总是单向前进CHANGELOG 是确认行为基准的唯一依据。升级建议在跨 major 升级前应完整过一遍 CHANGELOG.md 中目标版本区间内所有条目的Incompatible changes并结合 docs/release/backward-compatibility.mdx 中的兼容政策评估影响面。如何高效检索与利用这份 CHANGELOGCHANGELOG.md 体量巨大25510 行实际使用时建议采用以下检索路径确认当前版本与最新版本查看文件顶部前几行即最新 rolling 版本grep -n ^## Release CHANGELOG.md可列出全部版本号与行号本仓库中该命令输出 349 个条目。定位某个大版本的正式发布直接搜索## Release X.0.0 (即可找到 LTS 里程碑如## Release 8.0.0 (2024-12-09)。追踪某个 flag 的生命周期以 flag 名称为关键词搜索整个文件观察它从实验开关 → 改名 → 默认开启 → 移除的完整轨迹。核对维护分支的修复内容定位X.Y.Z补丁版本条目其Cherry picks与Important changes即该补丁的全部内容。结合版本归档文档对于特定大版本可切换到 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 等文档即可构建一套完整的版本管理与升级方法论。【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进