发布模型

报告问题 查看源代码 每夜 build · 8.0 · 7.4 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

支持矩阵

LTS 版本 支持阶段 最新版本 停止提供支持
Bazel 9 滚动 查看“逐步发布”页面 不适用
Bazel 8 有效 8.0.0 2027 年 12 月
Bazel 7 维护 7.4.1 2026 年 12 月
Bazel 6 维护 6.5.0 2025 年 12 月
Bazel 5 维护 5.4.1 2025 年 1 月
Bazel 4 已弃用 4.2.4 2024 年 1 月

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

发布版本控制

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 版本

  • 主要版本：大约每 12 个月从 HEAD 中提取一次新的 LTS 版本。新 LTS 版本发布后，会立即进入“有效”阶段，而之前的 LTS 版本会进入“维护”阶段。
  • 次要版本：活跃 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. 使用 Cherry-Pick Request 问题为 Bazel 维护者回移更改。

    • 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-discuss 上发布，Bazel 团队会监控和解决新版本的社区 bug 报告。

报告回归问题

如果用户在新的 Bazel 版本、候选版本甚至 Bazel at HEAD 中发现回归问题，请在 GitHub 上提交 bug。您可以使用 Bazelisk 对罪魁祸首的提交进行二分法，并在 bug 报告中添加此信息。

例如，如果您的 build 在使用 Bazel 6.1.0 时成功，但在使用第二个候选版本 6.2.0 时失败，您可以通过以下命令进行二分法：

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

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

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

规则兼容性

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