Releasing collections without release branches
Since no release branches are used, this section does not distinguish between releasing a major, minor, or patch version.
Release planning and announcement
Examine the collection to determine if there are merged changes to release.
According to the changes made, choose an appropriate release version number. Keep in mind that the collections must follow the semantic versioning rules. See Collection versioning and deprecation for details.
Announce your intention to release the collection in a corresponding pinned release issue or community pinboard of the collection and in the
Creating the release branch
Ensure you are in a default branch in your local fork. We use
mainin the following examples.
git status git checkout main # if needed
Update your local fork:
git pull --rebase upstream main
Checkout a new release branch from the default branch:
git checkout -b release_branch
galaxy.ymlcontains the correct release version number.
Generating the changelog
Add a changelog fragment
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.
For example:release_summary: |- This is the minor release of the ``community.mysql`` collection. This changelog contains all changes to the modules and plugins in this collection that have been made after the previous release.
If the content was recently moved from another collection (for example, migrating a module from one collection to another), ensure you have all related changelog fragments in the
changelogs/fragmentsdirectory. If not, copy them previously.
antsibull-changelog release --reload-plugins. This package should previously be installed with
pip install antsibull-changelog.
Verify that the
CHANGELOG.rstlooks as expected.
Commit and push changes to the
changelogs/changelog.yaml, and potentially deleted/archived fragments to the
git commit -a -m "Release VERSION commit" git push origin release_branch
Create a pull request in the collection repository. If CI tests pass, merge it.
Checkout the default branch and pull the changes:
git checkout main git pull --rebase upstream main
Publish the collection
Add an annotated tag to the release commit with the collection version. Pushing this tag to the
upstreamrepository will make Zuul publish the collection on 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.postgresql: 1.2.0" git push upstream NEW_VERSION
Wait until the new version is published on the collection’s Ansible Galaxy page. It will appear in a list of tarballs available to download.
Update the version in the
galaxy.ymlfile to the next expected version. Add, commit, and push to the
upstream’s default branch.
Add a GitHub release for the new tag. Title should be the version and content
See https://github.com/ansible-collections/community.xxx/blob/main/CHANGELOG.rst for all changes.
Announce the release through the Bullhorn Newsletter issue.
Announce the release in the pinned release issue/community pinboard of the collection mentioned in step 3 and in the