版本政策

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

Bazel 会维护一个 长期支持渠道 (LTS) 发布模式,其中主要版本每 9 个月发布一次,次要版本每 9 个月发布一次 版本每月发布一次本页将介绍 Bazel 发布政策 包括候选版本、时间表、公告和测试。

您可以在以下位置找到 Bazel 版本: GitHub

候选版本

新版本 Bazel 的候选版本通常在 。该作品由 GitHub 上的发布 bug 指示目标发布日期,并分配给当前的版本管理员。 候选版本应该通过所有 Bazel 单元测试,并且不会显示不需要的 在 Buildkite 上测试的项目中出现回归问题。

候选版本公布日期 bazel-discuss。 在接下来的几天中,Bazel 团队会监控社区 bug 报告, 回归问题。

发布

如果未发现任何回归问题,则候选版本会在 一周。不过,回归可能会导致候选版本的发布延迟。如果 则 Bazel 团队会择优挑选合适的 以修复这些回归问题。如果未发现其他回归问题 自第一个工作日起的 1 周后连续 2 个工作日 候选版本,则候选版本会被发布。

新功能发布后,我们不会为其择优挑选候选版本。 此外,如果某项新功能存在错误,我们可能会回滚到 候选版本。仅限可能会造成严重影响或破坏的错误 发布 build 会在定型后在候选版本中得到修复。

仅在次日为工作日的发布版本才会发布。

如果在最新版本中发现严重问题,Bazel 团队会创建 来修复补丁版本。由于此补丁会更新 而不创建新版本,候选补丁可以 在两个工作日后释放。

测试

在其中运行所有项目的每夜 build 使用 Bazel 运行 ci.bazel.build 以及发布二进制文件受 您会收到通知

候选版本发布后,其他 Google 项目(例如 我们会对 TensorFlow 进行完整测试, 测试测试套件(使用候选版本二进制文件)。如果您的某个关键项目 我们建议您创建一个自动化测试流程, 跟踪当前的候选版本,并报告所有回归问题。