-
Notifications
You must be signed in to change notification settings - Fork 144
ReleasingCollections
These instructions assume that publishing the collection is done via Zuul, and that antsibull-changelog is used for the changelog. Since no release branches are used, the instructions do not distinguish between releasing a major, minor or patch version.
- Make sure that
galaxy.yml
contains the correct version number. If not, update it! - Add a changelog fragment
changelogs/fragments/X.Y.Z.yml
with content:Add to git and commit.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 verbatimly inserted into the changelog.
- Run
antsibull-changelog release
(should previously be installed bypip install antsibull-changelog
). - Verify that
CHANGELOG.rst
looks good. - Add, commit and push changes to
CHANGELOG.rst
andchangelogs/changelog.yaml
, and potentially deleted/archived fragments. - Add a tag to the last commit with the collection version. Pushing this tag will make Zuul publish the collection.
- Update the version in
galaxy.yml
to the next (expected) version. Add, commit and push.
These instructions assume that publishing the collection is done via Zuul, and that antsibull-changelog is used for the changelog.
Announcements are made in the issues https://github.com/ansible-collections/community.general/issues/582 and https://github.com/ansible-collections/community.network/issues/81.
The new version is assumed to be X.0.0
.
-
Create a branch
stable-X
and push to the repository. -
Update the version in
galaxy.yml
in themain
branch to the next (expected) version. For community.general and community.network, it will beX.1.0
. Add, commit and push. From this point on, themain
branch is expecting changes for the next minor/major versions. -
If
X > 1
, replacechangelogs/changelog.yaml
with:ancestor: X.0.0 releases: {}
Add, commit and push.
(This ensures that every major release has a changelog describing changes since the last major release.)
-
Now switch back to the
stable-X
branch. -
In the
stable-X
branch, make sure thatgalaxy.yml
contains the correct version numberX.0.0
. If not, update it! -
In the
stable-X
branch, add a changelog fragmentchangelogs/fragments/X.0.0.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 verbatimly inserted into the changelog.
Add to git and commit.
Suggestion for text:
This is release X.0.0 of ``community.xxx``, released on 2020-xx-xx.
-
In the
stable-X
branch, runantsibull-changelog release
. -
In the
stable-X
branch, verify thatCHANGELOG.rst
looks good. -
In the
stable-X
branch, add, commit and push changes toCHANGELOG.rst
andchangelogs/changelog.yaml
, and potentially deleted/archived fragments. -
In the
stable-X
branch, add a tag to the last commit namedX.0.0
. Pushing this tag will make Zuul publish the collection. -
In the
stable-X
branch, update the version ingalaxy.yml
to the next (expected) version, i.e.X.1.0
. Add, commit and push. -
Write an announcement to the corresponding issue, and update the next (expected) version there.
-
Add GitHub release for this tag. Title should be the version, and content
See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes.
.
The new version is assumed to be X.Y.0
. All changes that should go into it are expected to be in the stable-X
branch (cherry-picked from main
, either manually or by bot).
- In the
stable-X
branch, make sure thatgalaxy.yml
contains the correct version numberX.Y.0
. If not, update it! - In the
stable-X
branch, add a changelog fragmentchangelogs/fragments/X.Y.0.yml
with content:Add to git and commit.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 verbatimly inserted into the changelog.
- In the
stable-X
branch, runantsibull-changelog release
. - In the
stable-X
branch, verify thatCHANGELOG.rst
looks good. - In the
stable-X
branch, add, commit and push changes toCHANGELOG.rst
andchangelogs/changelog.yaml
, and potentially deleted/archived fragments. - In the
stable-X
branch, add a tag to the last commit namedX.Y.0
. Pushing this tag will make Zuul publish the collection. - In the
stable-X
branch, update the version ingalaxy.yml
to the next (expected) version, i.e.X.(Y+1).0
. Add, commit and push. - In the
main
branch, update the version ingalaxy.yml
toX.(Y+1).0
as well. Add, commit and push. - Write an announcement to the corresponding issue, and update the next (expected) version there.
- Add GitHub release for this tag. Title should be the version, and content
See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes.
.
The new version is assumed to be X.Y.Z
, and the previous patch version is assumed to be X.Y.z
with z < Z
(probably z
is 0
, as patch releases should be uncommon).
This is a bit more complicated, since the stable-X
branch potentially already contains commits that should not go into a patch release.
- Checkout the
X.Y.z
tag. - Update
galaxy.yml
so that the version isX.Y.Z
. Add and commit. - Cherry-pick all changes from
stable-X
that were added afterX.Y.z
and should go intoX.Y.Z
. - Add a changelog fragment
changelogs/fragments/X.Y.Z.yml
with content:Add to git and commit.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 verbatimly inserted into the changelog.
- Run
antsibull-changelog release
. - Verify that
CHANGELOG.rst
looks good. - Add and commit changes to
CHANGELOG.rst
andchangelogs/changelog.yaml
, and potentially deleted/archived fragments. - Add a tag to the last commit named
X.Y.Z
. Pushing this tag will make Zuul publish the collection. - Write an announcement to the corresponding issue. Do not update the next expected release.
- Add GitHub release for this tag. Title should be the version, and content
See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes.
.
The data for this release is only contained in a tag, and not in a branch (in particular not in stable-X
). This is intended, since the next minor release X.(Y+1).0
already contains the changes for X.Y.Z
as well (since these were cherry-picked from stable-X
).
The new version is assumed to be X.Y.Z
, and the previous patch version is assumed to be X.Y.z
with z < Z
(probably z
is 0
, as patch releases should be uncommon).
- In the
stable-X
branch, make sure thatgalaxy.yml
contains the correct version numberX.Y.Z
. If not, update it! - In the
stable-X
branch, add a changelog fragmentchangelogs/fragments/X.Y.Z.yml
with content:Add to git and commit.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 verbatimly inserted into the changelog.
- In the
stable-X
branch, runantsibull-changelog release
. - In the
stable-X
branch, verify thatCHANGELOG.rst
looks good. - In the
stable-X
branch, add, commit and push changes toCHANGELOG.rst
andchangelogs/changelog.yaml
, and potentially deleted/archived fragments. - In the
stable-X
branch, add a tag to the last commit namedX.Y.Z
. Pushing this tag will make Zuul publish the collection. - In the
stable-X
branch, update the version ingalaxy.yml
to the next (expected) version, i.e.X.Y.(Z+1)
. Add, commit and push. - Write an announcement to the corresponding issue. Do not update the next expected release, since this is reserved for major and minor releases.
- Add GitHub release for this tag. Title should be the version, and content
See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes.
.
This Wiki is used for quick notes, not for support or documentation.
Working groups are now in the Ansible forum
Ansible project:
Community,
Contributor Experience,
Docs,
News,
Outreach,
RelEng,
Testing
Cloud:
AWS,
Azure,
CloudStack,
Container,
DigitalOcean,
Docker,
hcloud,
Kubernetes,
Linode,
OpenStack,
oVirt,
Virt,
VMware
Networking:
ACI,
AVI,
F5,
Meraki,
Network,
NXOS
Ansible Developer Tools:
Ansible-developer-tools
Software:
Crypto,
Foreman,
GDrive,
GitLab,
Grafana,
IPA,
JBoss,
MongoDB,
MySQL,
PostgreSQL,
RabbitMQ,
Zabbix
System:
AIX,
BSD,
HP-UX,
macOS,
Remote Management,
Solaris,
Windows
Security:
Security-Automation,
Lockdown
Tooling:
AWX,
Galaxy,
Molecule
Plugins:
httpapi