bug#38043: Python version language support

[Mike Frysinger]

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