发行经理指南

发行经理的职责是确保发布顺利进行。为了实现这一目标，他们需要协调：

• 拥有Ansible GitHub仓库提交权限的开发者

• 没有提交权限的贡献者

• 社区

• Ansible文档团队

预发行版：是什么以及为什么

预发行版是为了吸引测试人员。它为那些不习惯直接从源代码控制运行代码的人提供了一种获取早期版本代码进行测试并提供反馈的方法。为了确保我们获得关于版本的良好反馈，我们需要确保版本中的所有重大更改都包含在预发行版中。在最终发布之前，必须给测试人员时间来测试这些更改。理想情况下，我们希望预发行版之间有足够的时间，以便人们能够安装和测试一个版本一段时间。然后，他们可以花更多的时间使用新代码，而不是安装最新版本。

对于测试人员来说，合适的时间大约是两周。但是，为了使我们三到四个月的开发周期能够有效运作，我们将此时间压缩到一周；如果时间更短，则可能会导致人们花费更多时间安装代码而不是运行代码。但是，如果时间紧迫（发布日期无法推迟），最好发布包含新更改的版本，而不是为了给人们时间进行测试而推迟这些更改。人们无法测试未发布的内容，因此我们必须发布这些压缩包，即使人们觉得他们必须更频繁地安装。

Beta版

在Beta版中，我们知道仍然存在错误。我们将继续接受这些错误的修复。尽管我们会审核这些修复，但有时它们可能会具有侵入性，或者可能使代码的其他区域不稳定。

在Beta期间，我们将不再接受功能提交。

候选发行版

在候选发行版中，我们已经修复了所有已知的阻塞性错误。任何剩余的错误修复都是我们愿意从发行版中排除的错误。此时，我们需要用户测试来确定是否存在其他潜伏的阻塞性错误。

阻塞性错误通常是那些给用户造成重大问题的错误。回归错误更有可能被认为是阻塞性错误，因为它们会破坏现有用户对Ansible的使用。

发行经理将挑选修复新的发布阻塞性错误。发行经理还将选择是否接受代码隔离区域的错误修复，或将其推迟到下一个次要版本。非阻塞性错误本身不会触发新的发布；只有在阻塞性错误需要进行新的发布时，它们才会进入下一个主要版本。

最后一个RC应该尽可能接近最终版本。以下内容可能会更改：

• 版本号会自动更改，并且在从版本中删除预发行版标签时会有所不同。

• 如果确实需要，测试和docs/docsite/可能会有所不同，因为它们不会破坏运行时。但是，发行经理仍然可能会拒绝它们，因为它们有可能导致在发布过程中可见的破坏。

注意

我们想特别强调的是，代码（在bin/、lib/ansible/和setup.py中）必须保持相同，除非存在非同寻常的特殊情况。如果存在特殊情况，发行经理有责任通知希望测试代码的组。

Ansible发行流程

发行流程保存在单独的文档中，以便在发布过程中轻松更新。如果您需要访问权限进行编辑，请联系当前的发行经理之一。