Bazel 采用长期支持 (LTS) 发布模式，其中主要版本每 9 个月发布一次，次要版本每月发布一次。本页介绍了 Bazel 版本政策，包括候选版本、时间表、通告和测试。
您可以在 GitHub 上找到 Bazel 版本。
候选版本
每个月初，我们通常都会创建新版 Bazel 的候选版本。此工作通过 GitHub 上的发布 bug 进行跟踪，其中会指明目标发布日期，并分配给当前的发布经理。候选版本应通过所有 Bazel 单元测试，并且在 Buildkite 上测试的项目中不显示任何不必要的回归问题。
候选版本会在 bazel-discuss 上公布。在接下来的几天里，Bazel 团队会监控社区 bug 报告，以查看候选版本是否存在任何回归问题。
发布
如果未发现任何回归问题，候选版本会在一周后正式发布。不过，回归问题可能会延迟候选版本的发布。如果发现回归问题，Bazel 团队会将相应的精选集应用于候选版本，以修复这些回归问题。如果在第一个候选版本发布一周后，连续两个工作日内没有发现进一步的回归问题，则发布候选版本。
候选版本发布后，我们不会挑选新功能纳入其中。此外，如果新功能存在 bug，该功能可能会从候选版本中回滚。只有可能会严重影响或破坏发布 build 的 bug 才会在候选版本切割后修复。
只有在次日为工作日时，才会发布版本。
如果在最新版本中发现严重问题，Bazel 团队会通过对该版本应用修复程序来创建补丁版本。由于此补丁会更新现有版本，而不是创建新版本，因此补丁候选版本可以在两个工作日后发布。
测试
系统会使用在 HEAD 上构建的 Bazel 二进制文件和发布二进制文件，运行 ci.bazel.build 上运行的所有项目的每夜 build。系统会通知将受到破坏性更改影响的项目。
发布候选版本后，其他 Google 项目（例如 TensorFlow）会使用候选版本二进制文件在其完整测试套件中进行测试。如果您有使用 Bazel 的关键项目，我们建议您建立一个自动化测试流程，以跟踪当前的候选版本并报告任何回归问题。