# Ansible-2.10.0: Unfrozen until beta1

**URL:** <https://forum.ansible.com/t/ansible-2-10-0-unfrozen-until-beta1/33687>\
**Category:** Ansible Developer\
**Tags:** galaxy-ng\
**Created:** [August 27, 2020, 4:51pm UTC](https://forum.ansible.com/t/ansible-2-10-0-unfrozen-until-beta1/33687 "2020-08-27T16:51:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![tkuratom](https://avatars.discourse-cdn.com/v4/letter/t/b19c9b/32.png) [@tkuratom](https://forum.ansible.com/u/tkuratom)\
**Post date:** [August 27, 2020, 4:51pm UTC](https://forum.ansible.com/t/ansible-2-10-0-unfrozen-until-beta1/33687/1 "2020-08-27T16:51:15Z")

</div>

Greetings collection maintainers!

I have an important update to the Ansible-2.10.0 release schedule that  
affects you.

== Summary: The important bits ==

I announced feature freeze for Ansible 2.10.0 last week. However,  
after a group of collections told me that they have a coordinated new  
feature release on the first of September that they would like to be  
in 2.10.0, I looked at the schedule and proposed that we unfreeze and  
allow new features until beta1 is released next week (also the first  
of September... I'll be coordinating with them to make the Ansible  
beta release after their work is out).

\* If you can find a problem with this plan, please let me know here or  
on IRC as soon as possible. (I'm abadger1999 on irc.freenode.net).

\* If you are a collection owner and you want your particular  
collection to be shipped at a version older than the latest on the  
first of September, please let me know and I will make sure your  
collection is included into 2.10.0 at the version you specify.

We'll probably have feature freeze and the release of beta1 correspond  
in 2.11 and beyond as those two are tied together.

== Background: How did we arrived here ==

Yesterday I was alerted to the fact that a large number of collections  
maintained by Red Hat were going to have a coordinated release on the  
first of September. We had been alerted to this previously and  
everything seemed planned out. However, previously we had some  
miscommunication and I had not realized that the new releases  
contained new, but backwards compatible, features while the teams  
working on the collections had not realized that new features were  
forbidden after feature freeze.

We came up with several options:

\* Unfreeze until beta1 ships. Freezing before beta1 was scheduled so  
that there could be a testing period before the release of beta1 but  
the way we've decided to release, if there are major bugs in beta1  
which need fixes to be tested, we'll release beta2 in order to test  
that instead. This means we can be flexible with the time before  
beta1.

\* Allow these collection updates in as a special exception to the  
feature freeze. This seemed to be a little less collaborative as it  
would treat these collections differently than other collections just  
because the people managing them knew to talk to me directly.  
Ordinarily I'd take special exception requests to the Community IRC  
meeting on Wednesdays but this request came in a few hours after that  
meeting had ended so it wouldn't have a chance to be discussed at a  
meeting until after beta1 was released on Tuesday.

\* Continue to ship the old versions of the collections in 2.10.0 and  
then ship the new ones in 2.10.1. This would have been my second  
choice. But it would be more work. It requires manually tracking all  
of the collections being released (some of which will have new  
features and some which don't) and manually making sure that they do  
not get updated in the ansible package for 2.10.0. It would also  
leave out some important known bugfixes because they would be present  
in the same release as the new features.

The first option seemed to be the one with the least drawbacks so I  
asked several internal teams and on the #ansible-community irc channel  
if there were any objections to it. It seemed like an option that  
would work for everyone so I'm announcing it to a wider audience here.  
Again, if you see a problem with this, please contact me ASAP so that  
we can get a community discussion on this and figure out whether to  
push forward with a different option or delay beta1 a bit and make a  
decision at next week's community irc meeting.

== Implementation: What does unfreezing mean in practical terms? ==

When I release ansible-2.10.0beta1 next week, I will run a script  
which scans galaxy.ansible.com for the latest versions of the  
collections which will be included in 2.10.0. Under this revised  
plan, the script will take the latest non-prerelease version of the  
collections from galaxy and include it in the Ansible tarball. Under  
the previous schedule, it would have taken the latest version of the  
collection that did not include new features.

The script determines whether new features are present using the  
version number of the collections. The version number is supposed to  
use semantic versioning ( [https://semver.org/](https://semver.org/) ) which states that in a  
version number of X.Y.Z, either X or Y will be incremented if the  
release contains new features. So the script would only allow  
collections where the Z portion of the version had changed. For  
example:

If community.crypto-1.1.0 is the version present when we freeze, an  
upgrade to community.crypto-1.1.3 would be allowed. An upgrade to  
community.crypto-1.2.0 or community.crypto-2.0.0 would not be allowed.

Thanks for understanding as we work through our first release with all  
of these new deliverables,  
-Toshio

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [August 27, 2020, 7:12pm UTC](https://forum.ansible.com/t/ansible-2-10-0-unfrozen-until-beta1/33687/2 "2020-08-27T19:12:56Z")

</div>

Dear all,

just a quick reminder: if you haven't already done so, please use the  
unfreeze to add a \*\*changelog\*\* to your collection!

The preferred way is to use antsibull-changelog. You can read more  
about that at the following links:

\* [https://docs.ansible.com/ansible/devel/dev\_guide/developing\_collections.html#generating-changelogs-for-a-collection](https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#generating-changelogs-for-a-collection)  
\* [https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst](https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst)

We prefer this because it allows us to integrate your collection's  
changelog in the combined Ansible 2.10 changelog and porting guide. The  
current combined changelog can be found at:  
[https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst](https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst)  
The current combined porting guide can be found at:  
[https://docs.ansible.com/ansible/devel/porting\_guides/porting\_guide\_2.10.html](https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.10.html)  
(All 2.10.0 alpha/beta/rc entries will be collapsed to a final 2.10.0  
entry once that is released, same as for the Ansible-base changelog.)

If you prefer to write a changelog manually, or use another software  
which does not allow to create changelogs/changelog.yaml in your  
collection, please create an issue in  
[https://github.com/ansible-community/ansible-build-data/](https://github.com/ansible-community/ansible-build-data/) and tell us  
the URL of your changelog.

Thanks for your attention and best regards,  
Felix Fontein