发布模型

报告问题 查看源代码

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

支持矩阵

LTS 版本 支持阶段 最新版本 停止提供支持
Bazel 8 滚动 查看滚动版本页面 不适用
Bazel 7 有效 7.1.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 修复。

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

例如,每种类型的新版本将生成以下版本号:

  • 主要版本: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 Issue 向后移植更改(适用于 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-suite 上公布,Bazel 团队会监控候选版本的社区 bug 报告。
    • 如果发现新的阻碍因素,请返回上一步,在解决所有问题后创建新的候选版本。
    • 创建第一个候选版本后,不允许向版本分支添加新功能。
  7. 如果没有发现其他版本阻碍因素,则将候选版本作为正式版本推送

    • 对于补丁版本,请在最后一个候选版本发布后至少两个工作日后推送该版本。
    • 对于主要版本和次要版本,请在上一个候选版本发布后的两个工作日后推送版本,但不要早于第一个候选版本发布后的一周。
    • 发布版本仅在第二天是工作日的日子推送。
    • 该版本会在 bazel-suite 上发布,Bazel 团队会监控并解决新版本的社区 bug 报告。

报告回归问题

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

例如,如果您的构建在使用 Bazel 6.1.0 时成功,但在使用第二个候选版本 6.2.0 时失败,您可以通过

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

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

请记得将 Bazelisk 升级到最新版本,以使用 bisect 功能。

规则兼容性

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