发布经理指南

发布经理的目的是确保顺利发布。为了实现这一目标，他们需要在以下各方之间进行协调：

• 在 Ansible GitHub 存储库 中具有提交权限的开发者

• 没有提交权限的贡献者

• 社区

• Ansible 文档团队

预发布版本：是什么以及为什么

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

对于测试人员来说，合适的时间长度大约是两周。然而，为了使我们三到四个月的开发周期正常运行，我们将此压缩为一周；任何更少的时间都有可能导致人们花更多的时间安装代码而不是运行代码。然而，如果时间紧迫（发布日期不能拖延），最好是发布新的更改，而不是为了让人们有时间在两者之间进行测试而保留这些更改。人们无法测试未发布的内容，因此即使人们觉得他们必须更频繁地安装，我们也必须将这些 tarball 发布出去。

Beta 版本

在 Beta 版本中，我们知道仍然存在错误。我们将继续接受对这些错误的修复。虽然我们会审查这些修复，但有时它们可能具有侵入性或可能破坏代码的其他区域。

在 Beta 阶段，我们将不再接受功能提交。

候选发布版本

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

阻止程序错误通常是那些给用户带来重大问题的错误。回归更有可能被认为是阻止程序，因为它们会破坏当前用户对 Ansible 的使用。

发布经理将选择修复新的发布阻止程序。发布经理还将选择是否接受对代码隔离区域的错误修复，或将其推迟到下一个次要版本。就其本身而言，非阻止程序错误不会触发新版本；只有当阻止程序错误要求创建新版本时，它们才会进入下一个主要版本。

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

• 版本号会自动更改，并且会随着从版本中删除预发布标签而有所不同。

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

注意

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

Ansible 发布流程

发布流程保存在单独的文档中，以便在发布期间可以轻松更新。如果您需要访问权限来编辑此文档，请要求当前的发布经理之一添加您。