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
community
Matrix/IRC channel.
Creating the release branch
Ensure you are in a default branch in your local fork. We use
main
in 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
Ensure the
galaxy.yml
contains the correct release version number.
Generating the changelog
Add a changelog fragment
changelogs/fragments/X.Y.Z.yml
with content:
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/fragments
directory. If not, copy them previously.Run
antsibull-changelog release --reload-plugins
. This package should be installed withpip install antsibull-changelog
.Verify that the
CHANGELOG.rst
looks as expected.Commit and push changes to the
CHANGELOG.rst
andchangelogs/changelog.yaml
, and potentially deleted/archived fragments to theorigin
repository’srelease_branch
.
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
upstream
repository 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.yml
file to the next expected version. Add, commit, and push to theupstream
’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
community
Matrix/IRC channel.