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