|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: Replace uses of deprecated Python module distutils.sysconfig|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andres Freund <andres(at)anarazel(dot)de> writes:
> Thanks! Looks pretty good so far. Including on machines that were broken in
> take 1...
Just about all of the buildfarm has reported in now, and it's all good.
So now we need to discuss whether we want to back-patch this.
Pros: avoid configure warning now (not worth much); avoid outright
build failure on Python 3.12+ in future.
Cons: breaks compatibility with Python 2.6 and 3.1.
There are probably not many people using current Postgres builds
with 2.6 or 3.1, but we can't rule out that there are some; and
moving the compatibility goalposts in minor releases is generally
not nice. On the other hand, it's very foreseeable that somebody
will want to build our back branches against 3.12 once it's out.
3.12 is scheduled to start beta in roughly May of 2023 (assuming
they hold to their annual release cadence, which seems like a
The compromise I propose is to back-patch into branches that
will still be in-support at that point, which are v11 and up.
v10 will be dead, and it's perhaps a shade more likely than the
later branches to be getting used with hoary Python versions,
so I think the odds favor not changing it.
We could also wait until closer to 2023 before doing anything,
but I fear we'd forget until complaints start to show up.
I'd rather get this done while it's front-of-mind.
regards, tom lane
|Next Message||Andres Freund||2022-01-27 22:59:26||Re: A test for replay of regression tests|
|Previous Message||Andrew Dunstan||2022-01-27 22:51:52||Re: A test for replay of regression tests|