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 -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/CAPrnkaSL5_kpYrGO9Fn-3_Sb%3Dn89iOQZhoQfUtZUEkV1UO-QVg%40mail.gmail.com.
