Hi, On 2025-06-18 19:07:32 +0200, Robert Haas wrote: > On Wed, Jun 18, 2025 at 6:27 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > But it seems impossible to have rational discussions about this, > because - if I may exaggerate slightly for effect - some of us think > everyone with half a brain should upgrade within a week or two when a > new version comes out, while others of us think that there might be > someone out there who still has a working PDP-11. Since any policy > that anyone is likely to actually propose falls somewhere between > those two extremes, half of us are then bitterly unhappy with it.
Obviously that dynamic exists. But I think the root cause here isn't that we fundamentally can't find any compromise agreement, it's that we don't have a policy. Thus we get to have an iteration of the same debate everytime somebody is blocked by $old_os. Leading to everyone being incredibly frustrated and hardening their stances. I think what we need to do is to finally formalize the policy around this that we then can apply somewhat mechanical to most of the future cases. 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 Policy a) Personally I would say that a reasonable $age_criteria would be: If the expected PG major version release date is after the end of the "full support" window of a LTS distribution, the OS does not need to be supported. While I think that's rather reasonable, I *really* doubt that we could find agreement on that. Policy b) An IMO completely unreasonable position would be: If the expected PG major version release date is 5 years after the end of the "extended lifecycle" window of a LTS distribution, the OS does not need to be supported. I doubt anyone would argue that we need to go that far. Policy c) I guess a more credible, but from my perspective still fairly extreme, "long support window" position would be something like: If the expected PG major version release date is after the end of the "extended lifecycle" window of a LTS distribution, the OS does not need to be supported. To me that's too long support, because it means we'll support that major version of PG for up to 5 years after the OS vendor stopped supporting that version. BUT: I could live with that policy, even though I think it'd harm the project. Policy d) An IMO more reasonable compromise position could be something like this: If the expected PG major version release year + postgres support window (5 years) is after the year in which the "extended lifecycle" window of a LTS distribution ends, the OS does not need to be supported. That'd e.g. mean that PG 19 would need to support RHEL8, but PG 20 wouldn't, since $PG_20_release_year + $support_window > $RHEL_8_extended_lifecycle 2027 + 5 > 2031 That's personally still too aggressive for me, but I'd have an easier time living with this than with c). Policy e) Just like d), except that we would use not the end of the "extended lifecycle", but "end of maintenance support" as the cutoff. Greetings, Andres Freund
