发布经理指南
发布经理的目的是确保发布顺利进行。为了实现这一目标，他们需要协调以下事宜：
拥有 Ansible GitHub 仓库 提交权限的开发人员
没有提交权限的贡献者
社区
Ansible 文档团队
预发布：是什么以及为什么
预发布是为了吸引测试人员。对于那些不习惯从源代码控制运行的人来说，它们提供了一种获取早期版本的代码进行测试并向我们提供反馈的方式。为了确保我们能够获得关于发布的良好反馈，我们需要确保发布中的所有主要变更都包含在预发布中。在最终发布之前，必须给测试人员时间来测试这些变更。理想情况下，我们希望在预发布之间留出足够的时间，让用户能够安装并测试一个版本一段时间。这样他们就可以花更多时间使用新代码，而不是安装最新版本。
对于测试人员来说，合适的测试时间可能大约是两周。然而，为了让我们的三到四个月的开发周期正常运行，我们将其压缩到一周；如果时间更短，则会增加用户花费更多时间安装代码而不是运行代码的风险。但是，如果有时间紧迫（发布日期不可推迟），即使人们觉得他们必须更频繁地安装，也最好发布包含新变更的版本，而不是为了给人们时间进行测试而推迟这些变更。人们无法测试未发布的版本，因此我们必须发布这些 tarballs，即使人们觉得他们必须更频繁地安装。
测试版
在测试版中，我们知道仍然存在 bug。我们将继续接受针对这些 bug 的修复。尽管我们审核这些修复，但有时它们可能是侵入性的或可能破坏代码的其他区域。
在测试版期间，我们不再接受功能提交。
候选发布版
在候选发布版中，我们已经修复了所有已知的阻塞 bug。任何剩余的 bug 修复都是我们愿意从发布中排除的。此时，我们需要用户的测试来确定是否还有其他隐藏的阻塞 bug。
阻塞 bug 通常是会导致用户出现重大问题的 bug。回归 bug 更可能被认为是阻塞 bug，因为它们会导致当前用户无法使用 Ansible。
发布经理将 cherry-pick 新的阻塞 bug 的修复。发布经理还会选择是否接受针对代码孤立区域的 bug 修复，或将这些修复推迟到下一个次要版本。非阻塞 bug 本身不会触发新版本；它们只会出现在下一个主要版本中，前提是阻塞 bug 需要发布新版本。
最后一个 RC 应该尽可能接近最终版本。以下内容可能会更改
版本号会自动更改，并且会随着预发布标签从版本中删除而有所不同。
如果确实需要，测试和
docs/docsite/可能会有所不同，因为它们不会破坏运行时。但是，发布经理仍然可能拒绝它们，因为它们有可能在发布过程中导致可见的破坏。
注意
我们想特别强调的是，代码（位于 bin/、lib/ansible/ 和 setup.py 中）必须保持一致，除非存在非同寻常的特殊情况。如果存在特殊情况，发布经理有责任通知需要测试代码的组。
Ansible 发布流程
发布流程保存在 单独的文档 中，以便在发布过程中轻松更新。如果您需要编辑此文档的权限，请向当前的发布经理之一请求添加您。