发布集合
集合维护者会定期发布集合的所有受支持的稳定版本，前提是已合并了足够多的更改以进行发布。
准备发布集合
ansible-collections 组织下的集合在发布时遵循语义版本控制。有关详细信息，请参阅集合版本控制和弃用。
要准备发布，集合必须具有
公开可用的发布、版本控制和弃用策略。例如，这可以写在其 README 中或专门的置顶问题中。
当其发布管理者通知社区有关计划或已完成的发布时，会有一个置顶的问题。这可以与上面提到的发布策略问题结合使用。
一个变更日志。
在集合的存储库中标记的集合版本。
正在运行的 CI 管道。这可以通过使用 GitHub Actions、Azure Pipelines、Zuul 来实现。
所有 CI 测试都针对发布集合的提交运行。如果它们未通过，则不得发布集合。
如果您计划将新集合添加到 Ansible 包中，请参阅在 Ansible 中包含集合。
注意
您的集合必须通过 ansible-test sanity 测试。有关详细信息，请参阅测试集合。
集合版本控制和弃用
注意
集合必须遵守语义版本控制。
为了保持用户的向后兼容性，每个 Ansible 次要版本系列（5.1.x、5.2.x 等）将保持集合的主要版本不变。例如，如果 Ansible 5.0.0 包含 community.general 4.0.2，则每个 Ansible 5.X.x 版本将包含在构建时可用的最新 community.general 4.y.z 版本。即使 community.general 5.y.x 版本可用，Ansible 5.x.x 也永远不会包含该版本。主要集合版本更改将包含在下一个 Ansible 主要版本（在本例中为 6.0.0）中。确保包含在 6.0.0 中的当前主要集合版本在生成新的 Ansible 6.X.X 版本时至少会收到错误修复。
由于包含新的次要版本，因此您可以包含新功能、模块和插件。您必须确保不破坏向后兼容性。有关更多详细信息，请参阅语义版本控制。这尤其意味着
您可以在 补丁 版本中修复错误，但不能添加新功能或弃用任何内容。
您可以在 次要 版本中添加新功能和弃用内容，但不能删除任何内容或更改现有功能的行为。
您只能在 主要 版本中删除内容或进行重大更改。
确保如果在 5.x.y 中包含的集合版本中添加了弃用，则删除本身仅发生在 7.0.0 或更高版本中包含的集合版本中。确保以某种方式向贡献者和用户宣布发布、版本控制和弃用策略。有关如何执行此操作的示例，请参阅community.general 中的公告。您也可以在集合 README 文件中执行此操作。
集合变更日志
集合必须包含变更日志。为了使整个集合的变更日志具有一致的感觉，并确保 ansible 包中包含的集合存在变更日志，我们建议您使用antsibull-changelog来维护和生成此日志。
在发布之前，请验证您的变更日志的以下内容
发布集合的选项
有几种方法可以发布集合。如果您不知道使用哪种方法，请在 #ansible-community IRC 频道或 community Matrix 频道中提问。
本节假设使用Zuul完成集合的发布，并使用antsibull-changelog进行变更日志。
不使用发布分支进行发布
在以下情况下使用不使用发布分支进行发布
集合没有先前的主要版本。
自集合的
1.0.0版本以来，没有引入重大更改。
有关详细信息，请参阅不使用发布分支发布集合。
当需要引入重大更改时，您可以切换到下一种方法。
混合方法
在这种方法中，当前主要版本的发布是从 main 分支进行的，而旧主要版本的新版本是从这些版本的发布分支进行的。
使用发布分支进行发布
当引入了重大更改时，请使用发布分支进行发布。此方法通常仅由大型社区集合 community.general 和 community.network 使用。
有关详细信息，请参阅使用发布分支发布集合。