发布模型

<ph type="x-smartling-placeholder"></ph> 报告问题 查看来源 每晚 · 7.2。 · 7.1敬上 · 7.0 · 6.5 条 · 6.4。

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

支持矩阵

LTS 版本 支持阶段 最新版本 停止提供支持
Bazel 8 滚动 查看滚动发布页面 不适用
Bazel 7 有效 7.2.1 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 版本都可以在版本 页面。

发布版本版本控制

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

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

此外，预发布版本会以 日期后缀。

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

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

支持阶段

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

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

发布频率

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

滚动版本

  • 滚动版本与 Google Blaze 版本协调， 。这是下一个 Bazel LTS 的预览版 发布。
  • 滚动版本可能包含不兼容的更改。不兼容的标志是 推荐用于重大破坏性更改、推出不兼容的更改 应遵循我们的向后兼容性 政策。

LTS 版本

  • 主要版本：新的 LTS 版本预计将从 HEAD 中大幅削减 每 12 个月。新的 LTS 版本发布后，会立即进入有效 阶段，而上一个 LTS 版本将进入维护阶段。
  • 次要版本：活跃 LTS 轨道上的新的次要版本预计 每 2 个月发布一次。
  • 补丁版本：适用于 LTS 版本的活跃补丁和 预计会针对严重 bug 按需发布维护阶段 修复。
  • Bazel LTS 版本进入“弃用”阶段后， 维护阶段为 2 年。

如需了解计划发布的版本，请查看我们的版本 期 。

发布流程和政策

对于滚动发布，流程非常简单：大约每两周发布一次 根据与 Google 内部 Blaze 版本。由于发布计划比较快，我们不会向后移植任何更改 到滚动版本。

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

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

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

    • Bazel 维护人员可以请求择优挑选特定的提交 添加到某个版本分支该流程通过创建 GitHub 上的 cherry-pick 请求。以下是操作方法。

      1. 打开择优挑选请求
      2. 填写请求详细信息 <ph type="x-smartling-placeholder">
          </ph>
        • 标题：为请求提供简明扼要的描述性标题。
        • 提交 ID：输入您想要执行的提交的 ID 择优挑选如果存在多项提交，则将 以逗号分隔。
        • 类别：指定请求的类别。
        • 审核者：如果有多个审核者，请将他们的 GitHub 分隔开来 以逗号分隔 ID。
      3. 设置里程碑 <ph type="x-smartling-placeholder">
          </ph>
        • 查找“里程碑”部分，然后点击相应设置。
        • 选择相应的 X.Y.Z 版本拦截器。此操作 触发择优挑选机器人处理你的请求 “release-X.Y.Z”分支。
      4. 提交问题 <ph type="x-smartling-placeholder">
          </ph>
        • 填写完所有详细信息并设置里程碑后， 提交问题。

    • 择优挑选机器人将会处理该请求并通知 如果提交符合择优挑选的条件。如果 提交的内容是可择优挑选的 择优挑选提交时存在合并冲突，然后 聊天机器人将创建新的拉取请求拉取 请求获得 Bazel 团队成员批准后， 系统会择优挑选提交内容并将其合并到版本分支中。 如需查看已完成择优挑选请求的直观示例， 参阅这篇 示例 ，了解所有最新动态。

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

  6. 在已知版本分支的情况下，根据新的候选版本创建新的候选版本 版本拦截器已得到解决。

    • 候选版本宣布于 bazel-discuss， Bazel 团队会监控候选者的社区 bug 报告。
    • 如果发现新的发布阻碍，请返回上一步并 解决所有问题后创建新的候选版本。
    • 版本分支发布后，就不允许再向版本分支添加新功能。 首个候选版本创建完成择优挑选仅限于 修复。如果需要择优挑选，请求者必须回答 为什么说此次变更至关重要，有什么好处 该怎么办？此次变更带来哪些情况 回归？

  7. 如果没有其他版本，则将候选版本作为正式版本推送 已发现障碍

    • 对于补丁版本，请在发布至少 2 个工作日后推送版本 最后一个候选版本已发布
    • 对于主要版本和次要版本，请在两个工作日后推送版本 候选版本已推出，但不要早于该日期一周后 第一个候选版本已发布
    • 仅在次日为企业推出版本 。
    • 该版本的发布时间为 bazel-discuss， Bazel 团队会监控并处理社区 bug 报告， 发布。

报告回归问题

如果用户在新的 Bazel 版本、候选版本甚至 HEAD 的 Bazel，请报告以下 bug： GitHub。您可以使用 Bazelisk 对引发罪魁祸首的提交进行二分法处理，并将此信息包含在 bug 中 报告。

例如，如果构建使用 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 的文档 bisect 特征。

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

规则兼容性

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