From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jacob.champion@enterprisedb.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PG20 Minimum Dependency Thread
In-reply-to: 
 <CAOYmi+nVsoMRFp4u0oQ66-oPT6+NNAfhLvk5htthY5zkUOnbfA@mail.gmail.com>
References: 
 <CAOYmi+nVsoMRFp4u0oQ66-oPT6+NNAfhLvk5htthY5zkUOnbfA@mail.gmail.com>
Comments: In-reply-to Jacob Champion <jacob.champion@enterprisedb.com>
	message dated "Thu, 18 Jun 2026 13:01:47 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1399932.1781817745.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Jun 2026 17:22:25 -0400
Message-ID: <1399933.1781817745@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1399933.1781817745%40sss.pgh.pa.us>
Precedence: bulk

Jacob Champion <jacob.champion@enterprisedb.com> writes:
> 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%40eisentrau=
t.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.)

FWIW, my impression of that thread was that we had agreed on pretty
much everything except the value of N; if there was some later meeting
that discussed it further, I wasn't there.  Concretely, Andres said:

>> I think we should have a policy roughly along these lines:
>> 1) We don't remove support for OS versions unless they block something
>> 2) We don't remove support for OS versions in minor releases
>> 3) If support for an old OS version makes something harder, it can be r=
emoved,
>>    if and only if the OS is older than $age_criteria.
>> 4) As an alternative to removing OS support via 3), somebody desiring
>>    continued support for an older OS version can instead do the work to
>>    develop an alternative to removal of support within $reasonable_time=
frame

and we later agreed on my wording for $age_criteria:

>> 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=3D2 then we could drop RHEL8 support in PG 19; if we
>> set N=3D3 then it'd be PG 20 (measuring from end of full support
>> in May 2024).  I'd be okay with either outcome.

(hmm, I guess we didn't fill in $reasonable_timeframe, but that is
probably going to be case-by-case anyway)

> I propose that we adopt N=3D2. 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=3D3; I think it's
> just important that we arrive at some agreement on getting rid of RHEL
> 8.

It's too late to change anything for PG19, I think, so it kind of doesn't
matter today whether we set N to 2 or 3.  But I'd vote for N=3D3.  That
seems to match up better with LTS extended-support policies.

(I'm actually quite content with yum.pg.o cutting off support for
RHEL8 a year earlier than we stop supporting it at the source-code
level.  For one thing, we can pay attention to how much blowback
Devrim gets before we decide whether it's an okay source-code
change...)

			regards, tom lane