本页介绍了如何处理向后兼容性，包括从一个版本迁移到另一个版本以及如何传达不兼容的更改。
Bazel 不断发展完善，作为 LTS 主要版本的一部分发布的次要版本完全向后兼容。新的主要 LTS 版本可能包含不兼容的更改，这些更改需要执行一些迁移工作。如需详细了解 Bazel 的发布模型，请参阅发布模型页面。
总结
- 建议使用
--incompatible_*标志破坏更改。 - 对于每个
--incompatible_*标志，GitHub 问题都会说明行为变更，并提供迁移方案。 - 建议将不兼容的标志向后移植到最新的 LTS 版本，而不会默认启用该标志。
- 由
--experimental_*标志保护的 API 和行为可以随时更改。 - 切勿运行带有
--experimental_*或--incompatible_*标志的正式版 build。
如何遵循此政策
什么是稳定的功能？
一般而言，不带 --experimental_... 标志的 API 或行为被视为 Bazel 中受支持的受支持功能。
这些功能包括：
- Starlark 语言和 API
- 与 Bazel 捆绑的规则
- Bazel API，例如 Remote Execution API 或构建事件协议
- 标志及其语义
不兼容的更改和迁移方案
对于新版本中的每个不兼容更改，Bazel 团队的目标是提供迁移方案，帮助您更新代码（BUILD 和 .bzl 文件以及脚本中的任何 Bazel 用法、Bazel API 的使用等）。
不兼容的更改应具有关联的 --incompatible_* 标志和相应的 GitHub 问题。
我们建议将不兼容的标志和相关更改向后移植到最新的 LTS 版本，而不会默认启用该标志。这样一来，用户可以在下一个 LTS 版本发布之前进行不兼容的更改。
告知不兼容的更改
有关不兼容更改的主要信息来源是带有“不兼容的变更”标签的 GitHub 问题。
对于每项不兼容的更改，问题都会指定以下内容：
- 用于控制不兼容更改的标志的名称
- 已更改的功能说明
- 迁移方案
当不兼容的更改准备好与 HEAD 的 Bazel 一起迁移（因此，也与下一个 Bazel 滚动版本一起迁移）时，应使用 migration-ready 标签进行标记。在 HEAD 上翻转不兼容标志时，不兼容的更改问题会被关闭。