Make plan for Python 3.6 support #8983
Labels
area: pkging
area: python
priority: significant
Issues with higher than average priority that do not need to be in the current milestone.
Comments
bmw
added
area: pkging
area: python
priority: significant
|
I know I'm not part of the certbot team, but I do have a question: If upstream (i.e.: Python) isn't going to support 3.6 "indefinitely" and the RedHat team is nevertheless going to support Python 3.6 until EPEL7s EOL, why should certbot upstream (i.e.: you) keep supporting Python 3.6? Why would you be responsible? If they want to keep 3.6 around against all knowledge, why should you bear the burden? My personal opinion is the burden should be with the one deciding against upstream decisions. That said: is there any reason except upstream Python 3.6 being EOL to drop support for 3.6? It might also be reasonable to keep it around until a feature not available to 3.6 is required for something. |
bmw
pushed a commit
that referenced
this issue
Jan 21, 2022
Fixes #8983 Python 3.6 is now EOL: https://endoflife.date/python This is normally a good time to create warnings about Python 3.6 deprecation the Certbot upcoming release 1.23.0 so that its support is removed in 1.24.0. We have to say here that EPEL maintainers asked us to keep maintaining support of Python 3.6 because Python 3.7 will never be shipped to CentOS 7. This support would be needed in theory up to 2 more years, basically until CentOS 7 EOL in 2024-06-30. It has been said that we could support as a best effort until a reasonable need on Certbot side requires to drop Python 3.6. See #8983 for more information. However some of us (including me) consider that there is already a reasonable need right now. Indeed, keeping the support on Python 3.6 while the Python community globally moves away from it will pin implicitly some Certbot dependencies to the last version of these dependencies supporting Python 3.6 as the upstream maintainers decide to make the move. At any point in a future time, one of these dependencies could require an urgent upgrade (typically a critical uncovered vulnerability): then we would require to drop Python 3.6 immediately without further notice instead of following an organized deprecation path. This reason motivates to proactively deprecate then drop the Python versions once they are EOL. You can see the discussion in Mattermost starting from [this post](https://opensource.eff.org/eff-open-source/pl/ntzs9zy1fprjmkso3xrqspnoce) to get more elements about the reasoning. * Deprecate Python 3.6 support. * Ignore our own PendingDeprecationWarning
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I believe we were initially planning on not supported EOL'd Pythons, but EPEL is asking us not to do this and keep Python 3.6 support at https://bugzilla.redhat.com/show_bug.cgi?id=1813670. What are we going to do?
The text was updated successfully, but these errors were encountered: