-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Releasing, Versioning and Deprecation #81
Comments
The 1.0.0 release will be on Friday, July 31st. |
Version 1.0.0 has been released. From now on, bugfixes and new features that are merged need to be backported to the The 1.1.0 release is regularly scheduled for end of September. Since the Ansible 2.10.0 beta freeze is on 2020-08-14, we might release 1.1.0 already then. |
It was decided at the community meeting to do the 1.1.0 release on 2020-08-18 (Ansible 2.10 beta freeze), assuming that there is something new. |
Version 1.1.0 has been released. It will be included in Ansible 2.10.0. |
Version 1.2.0 will be released on 2020-09-30, i.e. next week Wednesday. |
Version 1.2.0 has been released. The next release (1.2.1 or 1.3.0, depending on content) will be at the end of November. |
bot_skip |
I plan to release 1.3.0 in three days (Wednesday, November 25th). |
1.3.0 has been released. The next 1.x.y release will be 1.3.1, whenever there is sufficient content. The next version including new features will be 2.0.0, planned for end of January 2021. |
1.3.1 will be released soon, probably the coming weekend, so that the removal announcements will make it into the next Ansible 2.10.x release. |
1.3.1 has been released. 1.3.2 might be released when needed, there's nothing planned currently. The next release should be 2.0.0 in the coming week. |
2.0.0 will be released on Wednesday, January 27th. The release process will start around 12:00 UTC. |
2.0.0 has been released! 🎉 The next stable-2 release will be 2.1.0 or 2.0.1, whatever comes first, when needed. 3.0.0 is planned for mid 2021 (when needed). |
1.3.2 has been released. 1.3.3 might be released when needed, there's nothing planned currently. |
2.0.1 has been released. 2.0.2 is not currently planned. |
At today's community meeting, we discussed the major release schedule for community.general and community.network. Since Ansible 4.0.0 has feature freeze on 2021-04-26, we plan to release community.network 3.0.0 shortly before that so it can get included in Ansible 4.0.0. This is earlier than the currently panned "mid of 2021". We plan to adjust the major release cycle in general so that major release are made shortly before a major Ansible release, i.e. community.network 4.0.0 will be released so it will be included in Ansible 5.0.0, etc. Since Ansible is supposed to have major releases in approximate 6 months intervals (same as the community.network major releases planned so far), this only shortens the current major release cycle, while keeping the distance between future major releases. |
|
|
community.network collection 5.0.0 has been released! See the changelog for details. |
The community.network collection versions 3.3.1 (Final |
FYI: Version 4 is EOL: it's been around long enough and it's a bit painful to maintain it:) |
Last updated by @Andersson007 2024-06-13
Introduction
This issue describes how and when community.network is released, and to announce updates to the release/versioning schedule. The next section (Next release) is always updated to contain the next version to be released. Other changes to this first post are always announced by separate posts in this issue.
Releasing guidelines
We use the Ansible collection releasing guidelines to conduct releases in this collections.
Next releases
6.0.0 (when needed)
5.X.Y (when needed, see the latest ones and changelog fragments to determine the next release)
4.0.Y (EOL)
Releasing schedule for major and minor versions
From then on:
Releasing schedule for patch versions
x.y.Z
until the last minor release of a major release branch will only be released when necessary. The intended frequency is never, they are reserved for packaging failures, or fixing major breakage / security problems.x.2.0
, generallyx.Y.0
) has been released, there will be bugfix releases forx.Y.z
.Versioning
galaxy.yml
in themain
branch will always contain the version of the next major or minor release. It will be updated right after a release.version_added
needs to be used for every new feature (like a new argument or return value, etc) and module/plugin, and needs to coincide with the next minor/major release version. (This will eventually be enforced by CI.)Branching
stable-x
branches.stable-x
is branched.stable-x
release branch afterx.0.0
, and until the last minor release forstable-x
has been released.stable-x
branches.Deprecation
Changelogs
trivial
category should then be used to document changes which are not important enough to end up in the text version of the changelog.)(x+1).0.0
changelog continues thex.0.0
changelog.x.y.0
changelog withy > 0
is not part of a changelog of a laterX.*.*
(withX > x
) orx,Y,*
(withY > y
) release.x.y.z
changelog withz > 0
is not part of a changelog of a later(x+1).*.*
orx.Y.z
(withY > y
) release.ancestor
feature (inchangelogs/changelog.yaml
) to point to the previous major release.The text was updated successfully, but these errors were encountered: