发布经理指南

发布经理的目的是确保顺利发布。为了实现这个目标，他们需要协调以下几个方面：

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

• 没有提交权限的贡献者

• 社区

• Ansible 文档团队

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

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

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

Beta 版

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

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

候选版本

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

阻塞错误通常是会给用户带来重大问题。回归错误更有可能被视为阻塞错误，因为它们会导致当前用户无法使用 Ansible。

发布经理将 cherry-pick 修复新出现的阻塞错误。发布经理还将决定是否接受针对代码隔离区域的错误修复，或者将这些修复推迟到下一个次要版本。非阻塞错误本身不会触发新的发布；只有在阻塞错误需要进行新的发布时，它们才会进入下一个主要版本。

最后一个 RC 应该尽可能接近最终版本。以下内容可能会发生变化

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

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

注意

我们特别强调，代码（在 bin/、lib/ansible/ 和 setup.py 中）必须保持一致，除非存在非同寻常的特殊情况。如果存在特殊情况，发布经理有责任通知需要测试代码的团队。

Ansible 发布流程

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