在以下两种情况下，Bazel Starlark 规则可能会破坏与 Bazel LTS 版本的兼容性：
- 该规则破坏了与未来 LTS 版本的兼容性，因为它所依赖的功能已从 Bazel 的 HEAD 中移除。
- 该规则破坏了与当前或旧版 LTS 版本的兼容性，因为它所依赖的功能仅在较新的 Bazel LTS 版本中提供。
同时，该规则本身也可能会向用户提供不兼容的更改。如果与 Bazel 中的重大更改相结合，升级规则版本和 Bazel 版本通常会让 Bazel 用户感到沮丧。本页介绍了规则作者应如何维护规则与 Bazel 的兼容性，以便用户更轻松地升级 Bazel 和规则。
可管理迁移流程
虽然显然无法保证每个 Bazel 版本与每个规则版本之间的兼容性，但我们的目标是确保 Bazel 用户的迁移流程保持可管理状态。可管理迁移 流程是指用户无需同时升级 规则的主要版本和 Bazel 的主要版本 的流程，从而 允许用户一次处理来自一个来源的不兼容更改。
例如，对于以下兼容性矩阵：
- 从 rules_foo 1.x + Bazel 4.x 迁移到 rules_foo 2.x + Bazel 5.x 不被视为可管理，因为用户需要同时升级 rules_foo 和 Bazel 的主要版本。
- 从 rules_foo 2.x + Bazel 5.x 迁移到 rules_foo 3.x + Bazel 6.x 被视为可管理，因为用户可以先将 rules_foo 从 2.x 升级到 3.x，而无需更改 Bazel 的主要版本，然后再将 Bazel 从 5.x 升级到 6.x。
| rules_foo 1.x | rules_foo 2.x | rules_foo 3.x | HEAD | |
|---|---|---|---|---|
| Bazel 4.x | ✅ | ❌ | ❌ | ❌ |
| Bazel 5.x | ❌ | ✅ | ✅ | ❌ |
| Bazel 6.x | ❌ | ❌ | ✅ | ✅ |
| HEAD | ❌ | ❌ | ❌ | ✅ |
❌：没有主要规则版本的任何版本与 Bazel LTS 版本兼容。
✅：至少有一个规则版本与最新版本的 Bazel LTS 版本兼容。
最佳做法
作为 Bazel 规则作者，您可以按照以下最佳实践确保用户获得可管理的迁移流程：
- 该规则应遵循语义 版本控制：同一 主要版本的次要版本向后兼容。
- HEAD 中的规则应与最新的 Bazel LTS 版本兼容。
- HEAD 中的规则应与 HEAD 中的 Bazel 兼容。为此，您可以
- 使用 HEAD 中的 Bazel 设置自己的 CI 测试
- 将您的项目添加到 Bazel 下游测试；如果 Bazel 中的破坏性更改影响您的项目，Bazel 团队会将问题提交到您的项目，您必须遵循我们的 下游项目政策 及时解决问题。
- 该规则的最新主要版本必须与最新的 Bazel LTS 版本兼容。
- 该规则的新主要版本应与该规则的先前主要版本支持的最后一个 Bazel LTS 版本兼容。
实现第 2 点和第 3 点是最重要的任务，因为这样可以自然而然地实现第 4 点和 第 5 点。自然而然地实现第 4 点和第 5 点。
为了更轻松地与 HEAD 中的 Bazel 和最新的 Bazel LTS 版本保持兼容性，规则作者可以：
- 请求将向后兼容的功能向后移植到最新的 LTS 版本，如需了解详情，请查看发布流程 。
- 使用 bazel_features 执行 Bazel 功能检测。
一般来说，借助推荐的方法，规则应该能够针对 Bazel 不兼容的更改进行迁移，并利用 HEAD 中的新 Bazel 功能，而不会降低与最新 Bazel LTS 版本的兼容性。