发布模型

报告问题 查看源代码 每晚

正如原始博文中所宣布的，Bazel 4.0 及更高版本为两种发布轨道提供支持：滚动版本和长期支持 (LTS) 版本。本页面介绍有关 Bazel 发布模型的最新信息。

支持矩阵

LTS 版本 支持阶段 最新版本 停止提供支持
Bazel 8 滚动 查看滚动发布页面 N/A
Bazel 7 有效 7.2.0 2026 年 12 月
Bazel 6 维护 6.5.0 2025 年 12 月
Bazel 5 维护 5.4.1 2025 年 1 月
Bazel 4 已弃用 4.2.4 2024 年 1 月

所有 Bazel LTS 版本都可以在 GitHub 上的版本页面上找到。

发布版本版本控制

Bazel 使用 major.minor.patch 语义版本控制方案。

  • 主要版本包含与上一版本不向后兼容的功能。每个主要 Bazel 版本都是一个 LTS 版本。
  • 次要版本包含从主分支向后移植的 bug 修复和功能。
  • 补丁版本包含重要的 bug 修复。

此外，预发布版本通过在下一个主要版本号后附加连字符和日期后缀来表示。

例如，每种类型的新版本都将生成以下版本号：

  • 主要：6.0.0
  • 次要版本：6.1.0
  • 补丁：6.1.2
  • 预发布：7.0.0-pre.20230502.1

支持阶段

对于每个主要 Bazel 版本，都有四个支持阶段：

  • 滚动：此主要版本仍处于预发布阶段，Bazel 团队从 HEAD 发布了滚动版本。
  • 有效：此主要版本是当前有效的 LTS 版本。Bazel 团队会将重要功能和 bug 修复向后移植到次要版本中。
  • 维护：此主要版本是处于维护模式下的旧版 LTS。Bazel 团队只承诺将安全问题和操作系统兼容性问题的重要 bug 修复向后移植到此 LTS 版本中。
  • 已弃用：Bazel 团队不再为此主要版本提供支持，所有用户都应迁移到较新的 Bazel LTS 版本。

发布频率

Bazel 会定期发布两个发布轨道的版本。

滚动版本

  • 滚动版本与 Google Blaze 版本协调，大约每两周从 HEAD 发布一次。这是下一个 Bazel LTS 版本的预览。
  • 滚动版本可能包含不兼容的更改。建议针对重大破坏性更改使用不兼容的标志；发布不兼容的更改时，应遵循我们的向后兼容性政策。

LTS 版本

  • 主要版本：新的 LTS 版本预计大约每 12 个月从 HEAD 剪切一次。新的 LTS 版本发布后，会立即进入“活跃”阶段，而上一个 LTS 版本会进入维护阶段。
  • 次要版本：Active LTS 轨道上的新的次要版本预计每 2 个月发布一次。
  • 补丁版本：处于活跃和维护阶段的 LTS 版本的新补丁版本预计将按需发布，以进行重大 bug 修复。
  • Bazel LTS 版本在维护阶段 2 年后进入“已弃用”阶段。

如需了解计划发布，请查看 GitHub 上的发布问题。

发布流程和政策

对于滚动版本，流程非常简单：大约每两周创建一个新版本，新版本与 Google 内部 Blaze 版本保持一致。由于发布时间安排较快，我们不会向后移植对滚动版本所做的任何更改。

对于 LTS 版本，请遵循以下程序和政策：

  1. 确定该版本的基准提交。
    • 对于新的主要 LTS 版本，基准提交是主分支的 HEAD。
    • 对于次要版本或补丁版本，基准提交是同一 LTS 当前最新版本的 HEAD。
  2. 使用基准提交中的 release-<version> 名称创建一个版本分支。
  3. 通过 PR 将更改向后移植到版本分支。
    • 社区可以建议向后移植的某些提交内容，方法是在相关 GitHub 问题或 PR 中回复“@bazel-io flag”，以将其标记为潜在的版本障碍，然后 Bazel 团队会对这些提交内容进行分类并决定是否向后移植这些提交内容。
    • 只有主分支上的向后兼容提交才能向后移植，还可以通过其他细微更改来解决合并冲突。

  4. 针对 Bazel 维护者，使用 Cherry-Pick Request 问题向后移植更改。

    • Bazel 维护人员可以请求为版本分支择优挑选特定的提交。此过程通过在 GitHub 上创建择优挑选请求启动。以下是操作方法。

      1. 打开择优挑选请求
      2. 填写请求详细信息
        • 标题：为请求提供简明扼要的描述性标题。
        • 提交 ID：输入要择优挑选的提交的 ID。如果存在多项提交内容，请用英文逗号分隔。
        • 类别：指定请求的类别。
        • 审核者：如果有多个审核者，请用英文逗号分隔其 GitHub ID。
      3. 设置里程碑
        • 找到“里程碑”部分，然后点击相应设置。
        • 选择相应的 X.Y.Z 版本拦截器。此操作会触发择优挑选聊天机器人来处理您对“release-X.Y.Z”分支的请求。
      4. 提交问题
        • 填写完所有详细信息并设置里程碑后，提交问题。

    • 择优挑选聊天机器人会处理请求，并通知提交内容是否符合择优挑选的条件。如果提交内容可以择优挑选（这意味着在择优挑选提交内容时没有合并冲突），聊天机器人将创建新的拉取请求。当 Bazel 团队成员批准拉取请求后，系统会择优挑选提交内容并将其合并到版本分支中。如需查看已完成的择优挑选请求的直观示例，请参阅此示例。

  5. 找出版本障碍，并修复在版本分支中发现的问题。

    • 在 Bazel CI 上，版本分支在提交后测试和下游测试流水线中使用相同的测试套件进行测试。Bazel 团队会监控版本分支的测试结果，并修复发现的任何回归问题。

  6. 在所有已知的版本拦截器都解决后，根据版本分支创建新的候选版本。

    • 候选版本在 bazel-discuss 上公布，Bazel 团队会监控候选版本的社区 bug 报告。
    • 如果发现新的发布障碍，请返回最后一步，在解决所有问题后创建新的候选版本。
    • 创建第一个候选版本后，不允许在版本分支中添加新功能；择优挑选仅限于关键修复。如果需要择优挑选，请求者必须回答以下问题：为什么这项更改至关重要？它有什么好处？此更改可能导致回归的可能性有多大？

  7. 如果找不到其他版本阻碍因素，请将候选版本作为正式版本推送

    • 对于补丁版本，请在上一个候选版本发布至少两个工作日后推送版本。
    • 对于主要版本和次要版本，请在最后一个候选版本发布 2 个工作日后推送该版本，但不要早于第一个候选版本发布一周后。
    • 仅在次日为工作日时推送版本。
    • 此版本在 bazel-COMMENT 上发布，Bazel 团队负责监控和处理新版本的社区 bug 报告。

报告回归问题

如果用户在新的 Bazel 版本、候选版本甚至 HEAD 的 Bazel 中发现回归问题，请在 GitHub 上提交 bug。您可以使用 Bazelisk 对“问题根源”提交进行二分法处理，并将此信息包含在 bug 报告中。

例如，如果使用 Bazel 6.1.0 构建成功，但在第二个候选版本 6.2.0 中失败，您可以通过以下代码执行 bisect：

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

您可以设置 BAZELISK_SHUTDOWN 或 BAZELISK_CLEAN 环境变量以运行相应的 bazel 命令，以便在需要重现问题时重置构建状态。如需了解详情，请参阅有关 Bazelisk bisect 功能的文档。

请务必将 Bazelisk 升级到最新版本才能使用 bisect 功能。

规则兼容性

如果您是规则作者，并希望保持与不同 Bazel 版本的兼容性，请查看规则兼容性页面。