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/ ) 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