发布模型¶

在文件的顶部，我们获得发布模型，它告诉我们诸如何时允许发布、允许哪些版本号等信息。

团队详情¶

“团队详情”部分告诉我们 PTL 和联络人，因此我们知道谁必须确认请求。 如果其中一个人提出了补丁，我们可以立即进行。 否则，我们希望确保其中一个人了解发布并批准它，以便团队知道我们不会发布他们知道存在问题的项目，例如。

标签¶

接下来，报告显示仓库的治理标签。 如果请求是稳定分支上的发布，并且项目具有该 stable:follows-policy 标签，将显示一个大型横幅，说明该发布需要由稳定团队批准。 即使可交付成果具有该标签，来自 master 的发布也不会包含该横幅。

接收新标签 X.Y.Z 的提交的详细信息¶

在“接收新标签…的提交的详细信息”部分（DEBUG 行下方），报告显示 git 认为之前的标签和应添加的补丁数量是多少。 这是一种快速验证我们没有在 1.9.0 之后标记 1.8.0 或类似情况的方法。

检查现有标签¶

下一部分显示已在正在标记的提交上存在的任何其他标签。 有时，一个团队会有 3 部分的可交付成果，但只有一个部分在发布中发生变化。 如果他们将这 3 个部分定义为 1 个可交付成果，他们应该标记所有 3 个部分。

包含版本号的所有分支¶

下一部分显示所有分支上的版本。 这有些重要，因为在从 master 创建稳定分支后的第一个发布中，我们希望确保版本号在前进。 验证作业要求至少版本号中的 Y 值递增。

包含提交的分支¶

下一步显示包含提交的哪个分支。 这对于确保没有人将 2 个分支合并在一起，并且我们没有从错误的分支发布很有用。

对于当前周期，发布应始终来自 master 分支。 稳定发布应来自适当的稳定分支。

与 HEAD 的关系¶

“与 HEAD 的关系”部分告诉我们发布是否会跳过任何提交。有时，有人在本地使用早于分支上最新提交的提交哈希。如果此部分没有说明正在发布 HEAD（Request releases from HEAD），那么最好要求提交者验证他们是否在执行他们想要执行的操作。有时他们不想发布额外的更改，有时他们不知道这些更改。对于里程碑标签，没有必要采取这种额外的预防措施，因为它们是基于日期的，并且即使它们不包含所有内容也没关系。我们预计在里程碑截止日期前后会有大量的变更和进展。

开放补丁、文档补丁和包含发布说明的补丁¶

接下来的几个部分显示匹配各种标准的开放补丁。这些在发布候选阶段的周期接近时很有用。当接近冻结日期时，发布团队可能会鼓励团队在发布之前批准未决的更改，以更新需求、发布说明和翻译。

需求变更¶

接下来的两个部分，“需求变更…”和“setup.cfg 变更…”，显示了自上次标记以来项目所做的依赖项更改。我们使用这些来确保 SemVer 规则的例外情况得到应用

• 标记常规发布（而不是像 alpha、beta 或 rc 这样的“预发布”）的项目需要在依赖项的最小版本发生更改或添加新依赖项时增加其版本号的 Y 部分。

该报告显示需求变更部分中的测试需求变更。这些不会触发 Y 版本变更。

发布 X.Y.Z 将包含¶

“发布 $version 将包含”部分显示了新发布中包含的实际更改——自上次标记版本以来的差异。审查的客观性就在这里。如果正在标记一个补丁发布，并且列表中的某项内容看起来像一个新功能，我们希望他们标记一个次要更新。如果列表中的任何内容似乎描述了一个不向后兼容的更改，我们希望他们标记一个主要版本更新。

git log 部分提供了日志消息的更详细视图。查找类似“删除类 X”或“将参数 Y 添加到方法 B”的注释，以指示发布将不向后兼容。如果发布没有新功能并且只修复了一个错误，则没有必要降低版本号。有时，如果只有一个更改并且显然是一个错误修复，我们可能会要求他们这样做，但大多数时候发布包含修复和功能的混合。

另一件事是查看是否只有 CI 配置更改。如果唯一的更改是 zuul 或 tox 配置，则没有理由标记发布，因为最终用户不会看到这些更改。这有时会发生在准备发布提案的脚本的项目中。

输出的下一部分（在 Release Notes 之后）显示了将出现在发布公告电子邮件中的相同文本。它包含在内，以便如果构建该文本失败，此作业将失败，并且可以修复 reno 输入文件，而不是让公告作业失败。

$PROJECT 的用户¶

输出的最后一部分是列表中包含当前交付版本的一个依赖项的项目列表。在冻结期间，该部分对于评估延迟发布的影响很有用。