向后兼容性

报告问题open_in_new 查看源代码open_in_new

本页介绍了如何处理向后兼容性（包括从一个版本迁移到另一个版本），以及如何传达不兼容的更改。

Bazel 在不断发展作为 LTS 主要版本的一部分发布的次要版本完全向后兼容。主要 LTS 版本之间的变更可能包含不兼容的变更，这些变更需要完成一些迁移工作。如需详细了解 Bazel 发布频率的工作原理，请参阅发布 Bazel 长期支持 (LTS) 版本。

摘要

1. 建议使用 --incompatible_* 标志进行重大更改。
2. 对于每个 --incompatible_* 标志，GitHub 问题都会说明行为的变化，并旨在提供迁移配方。
3. 受 --experimental_* 标志保护的 API 和行为可能随时更改。
4. 切勿运行带有 --experimental_* 或 --incompatible_* 标志的正式版 build。

如何遵守此政策

• 对于 Bazel 用户 - 如何更新 Bazel
• 面向贡献者 - 针对不兼容更改的最佳做法
• 对于发布管理员 - 如何更新问题标签和发布

什么是稳定版功能？

通常，不带 --experimental_... 标志的 API 或行为被视为 Bazel 中稳定受支持的功能。

其中包括：

• Starlark 语言和 API
• 与 Bazel 捆绑的规则
• Bazel API，例如 Remote Execution API 或 Build Event Protocol
• 标志及其语义

不兼容的更改和迁移配方

对于新版本中每个不兼容的更改，Bazel 团队都会提供一个迁移配方来帮助您更新代码（BUILD 和 .bzl 文件，以及脚本中使用的任何 Bazel、Bazel API 的使用等）。

不兼容的更改应具有关联的 --incompatible_* 标志和相应的 GitHub 问题。

传达不兼容的更改

不兼容更改的相关信息的主要来源是带有“incompatible-change”标签的 GitHub 问题。

对于每项不兼容的更改，问题都会指定以下内容：

• 控制不兼容更改的标志的名称
• 对功能更改的说明
• 迁移配方

当不兼容的更改准备好使用 HEAD 的 Bazel 进行迁移时（因此，也包括下一个 Bazel 滚动版本），应为其添加 migration-ready 标签。当“不兼容”标记在 HEAD 处翻转时，“不兼容的更改问题”就会得到解决。