使用发布分支发布集合

集合**必须**遵循语义版本控制规则。有关高级详细信息，请参阅发布集合。

发布计划和公告

  1. 在集合的相应固定发布问题/社区公告板以及#ansible-communityMatrix/IRC 频道中宣布您发布集合的意图。如果存在任何其他专用频道，请在其中重复公告。

  2. 确保所有其他存储库维护者都了解后续发布的时间。

发布主要集合版本

假定新版本为X.0.0。

  1. 确保galaxy.yml包含正确的版本号X.0.0。如果不是这种情况，请创建一个 PR 来更新它。这将使所有必须在X.0.0中删除的弃用项的健全性测试失败，因此这可能需要大量工作，并且应该在主要版本发布前几周完成。

  2. 检查集合中计划在主要版本中删除但健全性测试未报告的弃用项。使用过去的变更日志或在存储库中运行grep -r `X.0.0` plugins/。

  3. 如果您要发布community.general和community.network集合，请在相应的存储库中创建一个新的backport-X标签。从相应的现有标签复制样式和描述。

  4. 确保您在本地分支的默认分支中。这些示例使用main。

git status
git checkout main     # if needed

  1. 更新您的本地分支

git pull --rebase upstream main

创建发布分支

  1. 创建一个分支stable-X。将X替换为正确的数字，并将其推送到**上游**存储库，而不是origin。

git branch stable-X main
git push upstream stable-X

  1. 从main分支创建并检出到另一个分支

git checkout -b update_repo

  1. 将分支中galaxy.yml中的版本更新到下一个**预期**版本，例如X.1.0。

创建变更日志

  1. 将changelogs/changelog.yml替换为

ancestor: X.0.0
releases: {}

  1. 从changelogs/fragments/中删除所有变更日志片段。删除变更日志片段可确保每个主要版本都包含一个变更日志，描述自上次主要版本以来的更改。

  2. 添加并提交所有已进行的更改。将分支推送到origin存储库。

  3. 在集合存储库中创建拉取请求。如果 CI 测试通过，则合并拉取请求，因为main分支正在期待下一个次要/主要版本的更改

  4. 切换到stable-X分支。

  5. 在stable-X分支中，验证galaxy.yml是否包含正确的版本号X.0.0。

  6. 在stable-X分支中，确保changelogs/changelog.yml包含正确的祖先版本

ancestor: X-1.0.0
releases: {}

  1. 在stable-X分支中，添加一个变更日志片段changelogs/fragments/X.0.0.yml，其内容为

release_summary: |-
  Write some text here that should appear as the release summary for this version.
  The format is reStructuredText, but not a list as for regular changelog fragments.
  This text will be inserted into the changelog.

例如

release_summary: This is release 2.0.0 of ``community.foo``, released on YYYY-MM-DD.

  1. 在stable-X分支中，生成变更日志

antsibull-changelog release --cummulative-release

  1. 在stable-X分支中，验证CHANGELOG.rst是否符合预期。

  2. 在stable-X分支中，更新README.md，以便变更日志链接指向/tree/stable-X/，不再指向/tree/main/，并相应地更改徽章，例如，在 AZP 的情况下，将?branchName=stable-X添加到 AZP CI 徽章(https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI?branchName=stable-X)。

  3. 在stable-X分支中，添加、提交并将更改推送到README.md、CHANGELOG.rst和changelogs/changelog.yaml，以及可能已删除/归档的片段到**上游**存储库，而不是origin。

发布集合

  1. 在stable-X分支中，向最后一个提交添加一个带注释的标签，标签为集合版本X.0.0。将此标签推送到upstream存储库将使 Zuul 在Ansible Galaxy上发布集合。

git tag -n    # see current tags and their comments
git tag -a NEW_VERSION -m "comment here"    # the comment can be, for example, "community.foo: 2.0.0"
git push upstream NEW_VERSION

  1. 如果集合使用Zuul发布其版本，请等待新版本在集合的Ansible Galaxy页面上发布。它将显示在可下载的压缩包列表中。

  2. 如果在推送标签后几个小时内未出现发布压缩包，请尝试重新标记发布提交并再次推送标签。在stable-X分支中位于发布提交处

git tag --delete NEW_VERSION
git push upstream :NEW_VERSION
git tag -a NEW_VERSION -m "comment here"    # the comment can be, for example, "community.foo: 2.0.0"
git push upstream NEW_VERSION

  1. 为新标签添加一个 GitHub 发布。标题应为版本和内容，例如 - See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes。

  2. 通过Bullhorn Newsletter宣布发布。

  3. 在集合的固定发布问题/社区公告板以及#ansible-communityMatrix/Libera.Chat IRC 频道中宣布发布。

  4. 在stable-X分支中，将galaxy.yml中的版本更新到下一个**预期**版本，例如X.1.0。添加、提交并推送到**上游**存储库。

发布次要集合版本

假定新版本为X.Y.0。所有应该包含在其中的更改都应该以前从默认分支回补到stable-X分支。

创建变更日志

  1. 在 stable-X 分支中，确保 galaxy.yml 包含正确的版本号 X.Y.0。如果不是，请更新它。

  2. 在 stable-X 分支中，添加一个变更日志片段 changelogs/fragments/X.Y.0.yml，其内容为

release_summary: |-
  Write some text here that should appear as the release summary for this version.
  The format is reStructuredText, but not a list as for regular changelog fragments.
  This text will be inserted into the changelog.

  1. 在 stable-X 分支中，运行

antsibull-changelog release

  1. 在 stable-X 分支中，验证 CHANGELOG.rst 是否符合预期。

  2. 在 stable-X 分支中，添加、提交并将更改推送到 CHANGELOG.rst 和 changelogs/changelog.yaml，以及可能已删除/归档的片段到 **上游** 存储库，而不是到 origin。

发布集合

  1. 在 stable-X 分支中，为最后一次提交添加一个带注释的标签，标签为集合版本 X.Y.0。将此标签推送到 upstream 存储库将使 Zuul 在 Ansible Galaxy 上发布该集合。

git tag -n    # see current tags and their comments
git tag -a NEW_VERSION -m "comment here"    # the comment can be, for example, "community.foo: 2.1.0"
git push upstream NEW_VERSION

  1. 等待新版本在集合的 Ansible Galaxy 页面上发布。发布的版本将显示在一个可供下载的 tarball 列表中。

  2. 为新标签添加一个 GitHub 发布。标题应为版本和内容，例如 - See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes。

  3. 通过Bullhorn Newsletter宣布发布。

  4. 在集合的固定发布问题/社区公告板以及 #ansible-community Matrix/IRC 频道 中宣布发布。此外，您可以使用 GitHub 的发布系统来宣布它。

  5. 在 stable-X 分支中，将 galaxy.yml 中的版本更新为下一个 **预期** 版本，例如，如果您已发布 X.1.0，则下一个预期版本可能是 X.2.0。添加、提交并推送到 **上游** 存储库。

  6. 检出到 main 分支。

  7. 在 main 分支中

  1. 如果在下一个主要版本发布之前发布了更多次要版本，请将 galaxy.yml 中的版本更新为 X.(Y+1).0。创建一个专门的拉取请求并合并。

  2. 如果下一个版本将是新的主要版本，请创建一个拉取请求，在其中将 galaxy.yml 中的版本更新为 (X+1).0.0。请注意，健全性测试很可能会失败，因为将会有计划在 (X+1).0.0 中弃用的功能，这些功能由测试标记。

对于每个这样的弃用，请决定

  • 是否立即删除它们。例如，您可以删除完整的 modules/plugins 或删除重定向。

  • 是否向相应的 tests/sanity/ignore-*.txt 文件添加忽略条目并创建问题，例如，对于 modules/plugins 中删除的功能。

一旦 CI 测试通过，请合并拉取请求。确保此拉取请求的合并时间不要晚于 version_added 健全性测试预期新功能拉取请求的错误版本。

注意

在发布前的几天内进行一些删除操作是有意义的。这些删除必须发生在 main 分支中，并且不能回退。

发布补丁版本

假设新版本为 X.Y.Z，前一个补丁版本为 X.Y.z，其中 z < Z。由于补丁版本不常见，因此 z 通常为 0。

当预期更多次要版本时发布

  1. 检出 X.Y.z 标签。

  2. 更新 galaxy.yml，使版本为 X.Y.Z。添加并提交。

  3. 从 stable-X 中挑选所有在 X.Y.z 之后添加的并且应该进入 X.Y.Z 的更改。

  4. 添加一个变更日志片段 changelogs/fragments/X.Y.Z.yml，其内容为

release_summary: |-
  Write some text here that should appear as the release summary for this version.
  The format is reStructuredText but not a list as for regular changelog fragments.
  This text will be inserted into the changelog.

添加到 Git 并提交。

  1. 生成变更日志。

antsibull-changelog release

  1. 验证 CHANGELOG.rst 是否符合预期。

  2. 添加并提交对 CHANGELOG.rst 和 changelogs/changelog.yaml 的更改，以及可能已删除/归档的片段。

发布集合

  1. 为最后一次提交添加一个带注释的标签，标签为集合版本 X.Y.Z。将此标签推送到 upstream 存储库将使 Zuul 在 Ansible Galaxy 上发布该集合。

git tag -n    # see current tags and their comments
git tag -a NEW_VERSION -m "comment here"    # the comment can be, for example, "community.foo: 2.1.1"
git push upstream NEW_VERSION

  1. 等待新版本在集合的 Ansible Galaxy 页面上发布。它将显示在一个可供下载的 tarball 列表中。

  2. 为新标签添加一个 GitHub 发布。标题应为版本和内容，例如 - See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes。

注意

此版本的相关数据仅包含在标签中，而不是分支中，特别是 stable-X 中。这是故意的，因为下一个次要版本 X.(Y+1).0 也已经包含了 X.Y.Z 的更改，因为这些更改是从 stable-X 中挑选出来的。

  1. 通过Bullhorn Newsletter宣布发布。

  2. 在集合的固定发布问题/社区公告板以及 #ansible-community Matrix/IRC 频道 <https://docs.ansible.org.cn/ansible/devel/community/communication.html#real-time-chat> 中宣布发布。

当不再预期更多次要版本时发布

  1. 在 stable-X 分支中，确保 galaxy.yml 包含正确的版本号 X.Y.Z。如果不是，请更新它！

  2. 在 stable-X 分支中，添加一个变更日志片段 changelogs/fragments/X.Y.Z.yml，其内容为

release_summary: |-
  Write some text here that should appear as the release summary for this version.
  The format is reStructuredText, but not a list as for regular changelog fragments.
  This text will be inserted into the changelog.

  1. 在 stable-X 分支中生成变更日志。

antsibull-changelog release

  1. 在 stable-X 分支中，验证 CHANGELOG.rst 是否符合预期。

  2. 在 stable-X 分支中，添加、提交并将更改推送到 CHANGELOG.rst 和 changelogs/changelog.yaml，以及可能已删除/归档的片段到 **上游** 存储库，而不是到 origin。

发布集合

  1. 在 stable-X 分支中，为最后一次提交添加一个带注释的标签，标签为集合版本 X.Y.Z。将此标签推送到 upstream 存储库将使 Zuul 在 Ansible Galaxy 上发布该集合。

git tag -n    # see current tags and their comments
git tag -a NEW_VERSION -m "comment here"    # the comment can be, for example, "community.foo: 2.1.1"
git push upstream NEW_VERSION

  1. 等待新版本在集合的 Ansible Galaxy 页面上发布。它将显示在一个可供下载的 tarball 列表中。

  2. 为新标签添加一个 GitHub 发布。标题应为版本和内容，例如：See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes。

  3. 通过Bullhorn Newsletter宣布发布。

  4. 在集合的固定问题/社区公告板以及 #ansible-community Matrix/IRC 频道 中宣布发布。