On 2026-06-18 Th 6:26 PM, Tom Lane wrote:
Jacob Champion <[email protected]> writes:
On Thu, Jun 18, 2026 at 2:22 PM Tom Lane <[email protected]> wrote:
so it kind of doesn't
matter today whether we set N to 2 or 3.
I think it still matters for impending decisions. For example, we're
about to engineer how to backport a sliding window of Python across
the sliding window of backbranch support. Shorter windows tie our
hands less.
I dunno. One of the points of the allegedly-agreed-to policy
framework was
2) We don't remove support for OS versions in minor releases
A strict reading of that is that a released branch can't increase
its minimum required Python version.
Now maybe we can finesse that, like "you can build PL/Python and
associated contrib modules with Python >= X, but if you want to
run these optional tests, they require Python >= Y". Not sure
how comfortable I am with that. I definitely don't want to get
into a situation where we require buildfarm owners to have
Python >= Y installed, because then we will not have any testing
that proves we didn't break the other part. (So we'd need a
runtime check to skip these tests on too-old Python.)
In any case, if we do make such a decision, most likely we'd
use the same value of Y for all the active back branches.
So I think the value of N in the support policy really
only matters for future version-cutoff decisions.
Buildfarm owners are going to have to opt in to pytest, in the same way
that today they have to opt in to TAP tests, and in the same way there
will be up front tests to check that what's installed meets the
requirements. We could stick with X = 3.6 and make Y = 3.8.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
