Re: PG20 Minimum Dependency Thread
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-08T17:29:45Z
Lists: pgsql-hackers
On Fri, Jun 19, 2026 at 11:18 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > Solaris 11.3 was released in October 2015, with Python 2.6, 2.7, and > 3.6. Standard support ended in 2021. So with your stricter reading of > the OS support policy, and N=3, it's lucky that we happened to drop > Python 2 support already. Otherwise, Solaris 11.3 would pin Python 2.6 > support until PG17 drops off the matrix in 2028, fifteen years after > end of life. I pulled some data from the endoflife.date project [1] (which I haven't completely verified yet, but seems to be at least somewhat accurate). For a presumed PG20 release on 2027-09-23, our trailing edge of distro support might look something like below. Conclusions up front: OpenSSL 1.1.1 is a problem. With N=2, we'd drop SLES 12.5, which appears to be the final non-Oracle barrier to exit. (And I think we should just declare 1.1.1 unsupported for PG20, regardless of N, but in any case this gives weight to my preference of N=2.) I additionally think we should take Solaris and Oracle Linux out of the standard classification of "LTS". People who want to pay Oracle for extended support of out-of-date Postgres versions are free to do so without tying our development to RHEL8-vintage (or older) dependencies for the next seven(!) years, or forcing us to lock into an arbitrary snapshot of the Solaris rolling releases. We already don't support OL7 because of OpenSSL 1.0.2. If we did that, Python 3.9 looks within reach for PG20, which seems reasonable considering it'll already have been dead for two years. (It looks like LTS support for a spectrum of Pythons is now the norm rather than the exception, and we should start making decisions accordingly.) That'd only be a roadbump for our SUSE buildfarm owners, who'd need to install an additional package beside the base Python 3.6 in order to run Python scripts. = LTS Distros (N=3) = Amazon Linux 2023 (End of Service 2027, End of Life 2029) - Python 3.9 to 3.14+ - OpenSSL 3.0 Debian 12 Bookworm (EoS 2026, EoL 2028) - Python 3.11 - OpenSSL 3.0 Oracle Linux 7 (EoS 2024-12, EoL 2028) - Python 3.6 to 3.8 - OpenSSL 1.0.2 (!!) RHEL/Rocky/Alma/CentOS Stream 9 (EoS 2027, EoL 2032/2035) - Python 3.9 to 3.12+ - OpenSSL 3.0 (3.2? 3.5?) SLES 12.5 (EoS 2024-10, EoL 2027) - Python 3.4 to 3.6 - OpenSSL 1.1.1 (!) Solaris 11.4 (EoS 2031, EoL 2037) - Python 3.9 to 3.11 (rolling?) - OpenSSL 3.0 (3.5 planned?) Ubuntu 22.04 Jammy (EoS 2024-09, EoL 2027/2032) - Python 3.10 to 3.11 - OpenSSL 3.0 Windows 11 24H2 Enterprise (EoS 2027, EoL 2029/2034) Windows Server 2022 (EoS 2026, EoL 2031) = LTS Distros (N=2) = Only a few change: Oracle Linux 8 (EoS 2029, EoL 2032) - Python 3.8 to 3.12+ - OpenSSL 1.1.1 (!) SLES 15.6 (EoS 2025-12, EoL 2028) - Python 3.6 to 3.12+ - OpenSSL 3.1 Ubuntu 24.04 Noble (EoS 2029, EoL 2036) - Python 3.12 - OpenSSL 3.0 = Non-LTS Distros (N=0?) = I don't think this was explicitly discussed, but hopefully no one feels the need to guarantee support for non-LTS distributions that go EoL before we even release. (I.e. N is effectively zero for those distros.) But buildfarm operators still need some baseline, and here's what I think they could be for PG20: AIX 7.2 TL5 (EoL TBD?) - Python 3.10+ (?) - OpenSSL 3.0 Alpine 3.23 (EoL 2027-11) - Python 3.12 - OpenSSL 3.5 Fedora 45 (EoL 2027-11) - probably Python 3.15 - probably OpenSSL 4.0 FreeBSD 14.x (EoL 2028) - Python 3.11+ - OpenSSL 3.0 macOS 15 (Sequoia) (EoL 2027-09) NetBSD 10.x (EoL TBD) - Python 3.11 to 3.14 - OpenSSL 3.0 OpenBSD 8.0 (EoL TBD) - Python 3.11 to 3.14 - LibreSSL 4.4 OpenIndiana Hipster 2027.x (EoL TBD) - probably Python 3.14+ - probably OpenSSL 4.0 OpenSUSE Leap 16.0 (EoL 2027-10) - Python 3.13 - OpenSSL 3.5 Thanks, --Jacob [1] https://github.com/endoflife-date/endoflife.date