发布模型

报告问题 查看来源 Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

发布版本控制

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 版本会进入“维护”阶段。
  • 次要版本：预计每 2 个月发布一次有效 LTS 轨道上的新次要版本。
  • 补丁版本：对于处于活跃和维护阶段的 LTS 版本，预计会根据需要发布新的补丁版本，以修复严重 bug。
  • Bazel LTS 版本在维护阶段持续 2 年后，会进入弃用阶段。

如需了解计划发布版本，请查看我们在 GitHub 上的发布问题。

支持矩阵

LTS 版本 支持阶段 最新版本 停止提供支持
Bazel 7 滚动 查看 GitHub 发布页面 不适用
Bazel 6 有效 6.4.0 2025 年 12 月
Bazel 5 维护 5.4.1 2025 年 1 月
Bazel 4 维护 4.2.4 2024 年 1 月

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

发布程序和政策

对于滚动发布，流程非常简单：大约每两周会创建一个新版本，与 Google 内部 Blaze 版本的基准保持一致。由于发布周期较短，我们不会将任何更改向后移植到滚动发布版本。

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

  1. 确定版本的基准提交。
    • 对于新的主要 LTS 版本，基准提交是主分支的 HEAD。
    • 对于次要版本或补丁版本，基准提交是同一 LTS 版本的当前最新版本的 HEAD。
  2. 从基准提交创建名为 release-<version> 的发布分支。
  3. 通过 PR 将更改向后移植到发布分支。
    • 社区可以通过在相关的 GitHub 问题或 PR 上回复“@bazel-io flag”来建议回移植某些提交，以将其标记为潜在的发布阻塞问题。Bazel 团队会对这些问题进行分类，并决定是否回移植相应提交。
    • 只有主分支上的向后兼容提交可以向后移植，为解决合并冲突而做出的其他细微更改也是可以接受的。
  4. 识别发布阻塞问题并修复在发布分支上发现的问题。
    • 在 Bazel CI 上，发布分支会通过 postsubmit 和 下游测试流水线中的同一测试套件进行测试。Bazel 团队会监控发布分支的测试结果，并修复发现的任何回归问题。
  5. 在所有已知的发布阻塞问题都得到解决后，从发布分支创建新的候选版本。
    • 候选版本会在 bazel-discuss 上公布，Bazel 团队会监控社区针对候选版本提交的 bug 报告。
    • 如果发现新的发布阻塞问题，请返回上一步，并在解决所有问题后创建新的发布候选版本。
    • 在创建第一个候选发布版本后，不得向发布分支添加新功能。
  6. 如果未发现其他发布阻塞问题，则将候选版本推送为正式版本
    • 对于补丁版本，请在最后一个候选版本发布后至少两个工作日再推送版本。
    • 对于主要版本和次要版本，在最后一个候选版本发布后的两个工作日推送版本，但不得早于第一个候选版本发布后的一周。
    • 仅在第二天是工作日时推送版本。
    • 发布版本会在 bazel-discuss 上公布，Bazel 团队会监控并解决社区针对新版本提交的 bug 报告。

报告回归问题

如果用户在新的 Bazel 版本、候选版本甚至 HEAD 版本的 Bazel 中发现回归问题，请在 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 命令来重置 build 状态（如果需要重现问题）。如需了解详情，请参阅有关 Bazelisk bisect 功能的文档。

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

规则兼容性

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