-
Notifications
You must be signed in to change notification settings - Fork 90
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
The 2.0.0 Release #128
Comments
Context on the timeline of the pyOpenSSL deprecationThis is mostly blocked by Ubuntu Xenial. https://wiki.ubuntu.com/Releases - Xenial is EOS in April 2021 (and EOL 3 years later, but that's a bit far fetched since one needs to pay Canonical for support after EOS as far as I know). pyOpenSSL ( This means that we can't really drop support before that, since nearly nothing would work on such an old version of 1.x support?The nice thing about collections is of course that one can keep using the 1.x versions too, in case there's some older hosts around and as long as the changes are reasonable, I doubt that there's going to be much push-back on keeping a Other potential features for 2.0.0I plan to get again into https://github.com/ansible-collections/community.crypto/blob/main/plugins/module_utils/crypto/__init__.py states that it will go away eventually, 2.0.0 might be a good time for that. Dropping support for Python 2 (and maybe requiring a certain patch version of Python 3 or higher) could also be possible, but I'd first like to see how |
Thanks for the update and your thoughts! We need to still use pyOpenSSL for openssl_pkcs12 for some time I guess, since the new PKCS#12 support in cryptography is not good enough to replace pyOpenSSL yet, and it's so new that it will take a longer time until it's supported in the most common distros. But for all other modules, let's remove it for 2.0.0. The "v1" branch will be called stable-1 (as in c.g and c.n repos), so we can (hopefully) use the backport bot to do most of the backporting. At least when there are no conflicts :) I think I'll try to mainly backport bugfixes, if applicable. If there are bugfixes that are hard to backport, I'd only work on it if they are important, or if someone requests them. If someone else wants to backport features and/or bugfixes, I won't stop them. Removing https://github.com/ansible-collections/community.crypto/blob/main/plugins/module_utils/crypto/__init__.py in 2.0.0 (resp. removing its contents) sounds good. About dropping support for Python 2: ansible-base will not drop support for Python 2 on the remote side for a long time, and I guess we shouldn't either (maybe not as long as they, but long enough). And since almost all of our code runs on that side, that means no new features for most of it :/ Eventually it should also be possible to declare programmatically that a collection does not support certain Python versions; right now it isn't. Anyway, 3.0.0 sounds good for that (if we have nothing else that's more urgent and requires us to do a 3.0.0 earlier). |
How about scheduling 2.0.0 roughly next summer, so it can get included in Ansible 2.12? (More exact scheduling depending on when Ansible 2.12 will get scheduled :) ) |
Yeah, according to https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_11.html aiming for 2.11 will be just a little bit too early and I'm sure people will still keep Ubuntu 16.04 boxes around for a bit anyways. Aiming for summer 2021 (so there's enough time to test until everything lands in the 2.12 "full" release) is probably the best way forward. |
BTW, that's the roadmap for ansible-base :) The roadmap for Ansible is at https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_2_11.html It's pretty empty right now, but I know that the current planning is to get this out in the first months of 2021. (This also means that Ansible 2.11 will include ansible-base 2.10. Ansible 2.12 will include ansible-base 2.11.) |
I think what we can also do is get rid of the vendored ipaddress.py file. ipaddress is part of the Python stdlib since Python 3.3, and can easily be installed for older Python versions (https://pypi.org/project/ipaddress/). It is also a requirement of newer |
BTW, this is the current planning for the next Ansible releases: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw 3.0.0 will be released mid-February (feature freeze: February 2nd), and 4.0.0 (with ansible-core 2.11) is planned for mid-May (feature freeze: probably end of April for beta1). Ansible 5.0.0 will probably be released at the end of the year. ansible-core seems to be heading for a new release every ~6 months, and Ansible will probably follow a bit later (this is somewhat tentatively). So I guess we should definitely have 2.0.0 out for Ansible 5.0.0, and for Ansible 4.0.0 it's probably a bit too early. So late summer/fall is probably a good time. |
Getting rid of our vendored copy of |
According to the Ansible 5 roadmap, community.crypto 2.0.0 needs to be released by October 25th (https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_5.html) to get included in Ansible 5.0.0. I guess we can start somewhen in September by creating a |
The schedule was postponed a bit, the deadline is now November 8th. I guess we can still start in September, but more at the end of it. |
@MarkusTeufelberger @Ajpantuso the end of September is coming up :) Are there any more features that should go into 1.10.0, or should be make a 1.9.4 release for the current bugfixes in |
Once we're done with 1.x.y releases, the procedure would be as follows:
Does that sound reasonable? |
I'm okay to proceed without anything additional in 1.10.0. |
Same here, looking forward to (mostly) ripping out pyOpenSSL! :-) |
Great! I'll do the @MarkusTeufelberger I hope you haven't been waiting to rip parts out yourself, since I'm afraid I already killed most of it that can be removed for 2.0.0 in #273 ;) |
I'll create a 1.9.5 release tomorrow from the stable-1 branch so we have a release that supports cryptography 35.0.0. |
1.9.5 is out. |
The only larger piece required for 2.0.0 is #290. Once that's merged, the |
Ok, I guess we can proceed with 2.0.0 soon. Does anyone mind if I create a 2.0.0 release this weekend? Or does someone wants to wait a few days more (say, the weekend thereafter)? |
2.0.0 has been released! 🎉 |
The 2.0.0 release will happen in the future. The main target(s):
ipaddress
in module_utils.Timeframe: September/October 2021, 2.0.0 needs to be released by 2021-11-08 (https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_5.rst).
The text was updated successfully, but these errors were encountered: