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