Re: What's our minimum supported Python version?

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> There are approximately 6 buildfarm members with RHEL 7 or CentOS 7, so
> in that sense, "support" means that everything is expected to work
> there. And some amount of work has been done recently to keep that
> support alive.

Yeah. Devrim's choice of what to package is not project policy,
it's just his own personal allocation of resources.

> (But I'm confused now because I see Python 3.6 on both the RHEL 7 and
> the RHEL 8 animals. So it's not clear how representative these animals
> are especially with respect to the Python versions.)

Per wikipedia, RHEL7 was released mid-2014, so the latest Python
version 7.0 could possibly have shipped with is 3.4 (released
2014-03) and much more likely they shipped 3.3 (2012-09). However,
you can if you choose install later Python versions, and you
have control over which version /usr/bin/python3 points at.
(At least this is true on the RHEL8 box I am looking at, and
I'm fairly sure it was so on RHEL7 too.) Similarly, Python 3.6
seems to be the baseline default on RHEL8 --- and the timing
more or less matches up, as 3.7 was released not long before
they would have been freezing the RHEL8 feature set. But you can
install 3.8, 3.9, 3.11, and/or 3.12 without going outside the
universe of Red-Hat-supported packages.

So what's that mean for us? "We still want to support RHEL7" turns
out to be squishier than one might think. But I don't think we
really want to promise to work with Python 3.3, especially given
the lack of any buildfarm representation of that. In the other
direction, yeah we could insist that RHEL users install some
later Python version, but I think we'd get push-back. The point
of using an LTS distro is, well, stability. The users want to
decide which packages they are comfortable with updating.

I'm still content with the idea of deciding that 3.6 is now our
cutoff. If someone comes along and complains because
oauth_server.py doesn't work on an older version, it's up to them
to provide a patch. If/when we want to include some Python code
that can't reasonably be made to work on 3.6, we can reconsider.

regards, tom lane