发布经理指南

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

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

  • 没有提交权限的贡献者

  • 社区

  • Ansible 文档团队

预发布：内容和原因

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

测试人员可能需要两周左右的时间。但是，为了使我们三个到四个月的开发周期有效，我们将此时间压缩为一周。如果时间更短，可能会导致用户更多地花时间安装代码而不是运行代码。但是，如果时间紧迫（发布日期不可推迟），最好是发布带有新变更的版本，而不是为了给用户提供测试时间而推迟这些变更。用户无法测试未发布的代码，因此我们必须发布这些代码，即使用户感到他们必须更频繁地安装。

Beta 版本

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

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

发布候选版本a

在发布候选版本中，我们已经修复了所有已知的阻塞 bug。任何剩下的 bug 修复都是我们愿意不在本次发布中包含的。此时，我们需要用户测试来确定是否还有其他隐藏的阻塞 bug。

阻塞 bug 通常是指会导致用户出现重大问题。回归问题更有可能被认为是阻塞 bug，因为它们会破坏用户当前对 Ansible 的使用。

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

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

  • 版本号会自动更改，并且在从版本中删除预发布标签时会发生变化。

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

注意

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

Ansible 发布流程

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