PG20 Minimum Dependency Thread

...because I don't see one yet, and upcoming things like the Python
test port are going to need clarity in advance, and I wanna stir up
trouble right before I go eat lunch.

= Background =

The most recent (mailing list) discussions I am aware of are at

[1] https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us (Python)
[2] https://postgr.es/m/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org
(Meson)

The discussion in [2] ended with a growing consensus that we need _a_
policy, and Andres proposed a framework of one, but I don't think one
was actually chosen. (If I missed that somewhere on the list, or at an
in-person meeting, I apologize. Most of this email is moot if that's
the case.)

The partial list of dependency versions for PG19 is here, and if you
know what's pinning one of the blank rows, please consider filling it
in:

https://wiki.postgresql.org/wiki/Minimum_Dependency_Versions

But I intend this thread to be about PG20, which will release next
year (2027) and will presumably be supported until 2032.

= My Votes =

For PG20, I want to drop support for RHEL 8 (and prior -- we still
have CentOS 7 machines testing HEAD in the buildfarm).

For me, the most important reason is OpenSSL, because upstream has
already reached 4.0 and we still can't drop code written for 1.1.1. An
additional reason is Python 3.6, which was EOL in 2021; I'd like to
avoid pinning that for another six(!) years. It looks like ninja/meson
get a boost too.

RHEL 8 users in the paid Maintenance Support window (ending 2029) will
still be able to use PG19 for its entire lifetime. And the maintenance
window for RHEL 7 is long gone. People can update their machines if
they want shiny new features.

Cherry-picking from Tom's email on the topic in [2], which may not be
representative of his opinion today:

> Maybe we could compromise on
>
> If the expected PG major version release date is more than N years
> after the end of full support for an LTS distribution, that OS
> version does not need to be supported.
>
> Defining it relative to "full support" also reduces questions about
> whether extended support means the same thing to every LTS vendor.
>
> If we set N=2 then we could drop RHEL8 support in PG 19; if we
> set N=3 then it'd be PG 20 (measuring from end of full support
> in May 2024). I'd be okay with either outcome.

I propose that we adopt N=2. I think we should have stopped supporting
RHEL8 this year (our yum repos won't be shipping PG19 builds for
RHEL8). But I won't complain if consensus forms on N=3; I think it's
just important that we arrive at some agreement on getting rid of RHEL
8.

--Jacob