On 18 Jan 2022 16:15, Karl Berry wrote: > i'm inclined to drop support for <Python-3.6. > > My recollection is, plenty of people are still using <3.6, EOL or not. > Tempting though it is.
dissertation follows. i know it's a lot, and i don't normally like writing this much at a time, but i think this is something we need to agree to & write down because it's a promise/commitment to users, and will have very long-term implications for us. if you want to skip to the end for "My proprosal", feel free, and if you disagree with parts, you can backup and read my logic :p. i don't think we can reasonably support every version of Python with the latest automake release forever. we don't even support every version now, and i don't think we're going to backfill. fairly certain we don't work with Python 0.x, or Python 1.x, and i suspect Python 2.[0-6] is rotting. so we already have a version cut off line. the question is where do we draw that line, and when do we move it ? let's say that we never remove support for versions we've added. i.e. once a version is included, it'll always be here. how do we make sure it continues to work ? practically speaking, it's impossible for us to test. many distros have already long ago deleted Python 3.[012], are in the process of deleting Python 2.7 now, and it's only getting worse. are automake developers expected to manually download & build every Python version ? and when those versions stop compiling against current C runtimes (compilers/libraries), they have to backport fixes to get them working ? for a diff project, i've already done this, and i know that old releases do not unpack+configure+compile+execute without backports (as in, `./python` segfaults). now you might argue that devs can install old distros. doing that in a chroot or in a container (e.g. docker) doesn't work as the kernel removes/disables features that old binaries need. i've seen this with CONFIG_COMPAT_VDSO being removed -- old binaries now just segfault. which means you need to downgrade your kernel and/or re-enable settings that include known security bugs. now you might argue that devs can always install old distros in VMs and thus isolate themselves. but those VMs will have known security issues at the security level (i.e. OpenSSH and such have known exploits). ok ok, you should have those VMs be firewalled, and only accessible from localhost. hopefully you can still find install media for these distros, and their network packages can still be installed. except their root CA store is going to be expired, and they'll be unable to access any HTTPS sites, so they won't be able to download anything from the network. let's back up a little. automake doesn't exist for its own sake, it exists purely for its users (other developers). we add & maintain features purely because they want them. so what do those developers want ? do they want to support Python 2.[0-7] & 3.[0-9] in a single release of their own software ? in my experience, that pretty much never happens. Python devs tend to say "we've dropped support for Python X.Y with current versions, so if you want that, you'll need to download an old release". i have seen projects doing the Python 2.7 + Python 3.x support dance, but that has largely evaporated with Python itself finally cutting Python 2 off. now i only see projects saying "if you want Python 2, grab an old release". similarly, while Python 3.[0-9] has been done by some projects, even that is evaporating. i think that was largely predicated on the Python project being very backwards compatible and not making breaking changes, and they were doing that only as a carrot to get people off of Python 2. now that they've killed Python 2, they're starting to make breaking changes with Python 3.10+, and that is only going to accelerate, which means projects are going to realize that the effort to support Python 3.0 - 3.10+ in a single codebase is a lot harder than it used to be. now throw in alternative runtimes (cython, pypy, jython, etc...) and the variety of virtual environments (venvs). are we going to support those forever too ? so if our users don't want every Python version, and keeping support for old versions is impossible for us to validate, when can we move the post ? to help the discussion, i indexed Python versions in Debian & Ubuntu releases starting from ~2008. from that we can <Python-2.5 is already gone, and that <Python-2.7 is gone by 2016 (Debian Squeeze really dragged 2.6 out). we see that Python 3.0 never makes an appearance, and Python 3.1 is gone by 2016. https://gerrit.googlesource.com/git-repo/+/HEAD/docs/release-process.md#Project-References alternatively, do we take a similar position to Python projects ? if you want to support a Python version X.Y, use an old release of automake ? # My proprosal what if we said something like: Automake guarantees releases will support all Python versions that are still supported by the Python project at the time of the Automake release. Support for EOL versions of Python are not guaranteed, but will be considered as long as it is not onerous to do so, and there are large supported distros including them. If you need to support older Python versions, please use a previous Automake release. that means right now: * we have to support Python 3.7 (it goes EOL upstream in 2023) * we can probably keep Python 3.6 easily enough * Python 3.5 probably should be kept since it's in Ubuntu Xenial, and that doesn't go EOL until Apr 2024 * Python 3.4 might be kept since it's in Ubuntu Trusty, and that doesn't go EOL until Apr 2022 * Python 2.7 might be kept since it's in Debian Bullseye, and that doesn't go EOL until Apr 2026 * Python 3.[0-3] can be kept as long as they don't require unique changes * Python 2.[0-6] can be kept as long as they don't require unique changes * as soon as we get reports that Python 3.[0-3] or 2.[0-6] don't work, we respond by deleting them. or if we make changes that seem like they won't work, we delete them. * we update the manual to state clearly: * Python 2.7 & 3.4 - 3.10 are fully supported * Python 2.0 - 2.6 & 3.0 - 3.3 should work, but are not tested * Python <2.0 do not work are not supported at all -mike
signature.asc
Description: PGP signature