Re: PG20 Minimum Dependency Thread

Hi,

On Mon, 2026-07-13 at 08:44 -0700, Jacob Champion wrote:
> I think the runtime dependency for "supported LTS platforms" should
> generally be the base Python version that is shipped, so that our
> packagers aren't splitting their ecosystems by default. We don't want
> our supported platforms to have to navigate package dependency hell
> for core Postgres. (If packagers actually think it'd be fine for a
> specific platform, they can tell us and then we can bump those up. But
> I don't think we should assume that's the case.)
>
> So in the email you replied to, I'm saying that 3.9 looks like a
> reasonable floor for the *build-time* dependency to me, with the
> caveat that SLES testers and packagers will have a 3.6 runtime version
> and a 3.9 build-time version that we will need to navigate. If that's
> not acceptable for some reason -- it's been a while since I've had to
> author RPM specs, but I thought I remembered that they allow for
> pretty good dependency separation? -- then IMO the floor would need to
> drop to 3.6.
>
> Copied Devrim since he'd probably have opinions re: SLES.

Last year I started building some (many) Python software that supports
Patroni (and also Patroni itself) against recent and "supported" Python
versions, so build infra has already these):

Fedora 43,44: Python 3.14. Least problematic ones, for sure.

RHEL 8,9 and 10: Python 3.12 : This means users can access these
packages natively without adding any 3rd party repos. Please note that
RHEL 9 and 10 (which is good for PG 20+) also support Python 3.14 (EOL
Oct 2030).

SLES 15.X: Python 3.11 (has currently limited support for Python 3.13).

SLES 16.0: Python 3.13 (Per 
https://documentation.suse.com/sles/16.0/html/SLE-packages-lifecycle/index.html#packages-lifecycle-python
"The current plan (subject to change) is to provide newer Python
versions in future SUSE Linux Enterprise 16.x releases. "

So I think from RPM packaging point of view Python 3.11 is the base on
SLES 15, and the rest can do even more.

-HTH.

Regards,

--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
BlueSky: @devrim.gunduz.org , @gunduz.org