Re: PG20 Minimum Dependency Thread

Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)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%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.)

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 removed,
>> 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_timeframe

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=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.

(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=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.

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=3. 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