Andres Freund <and...@anarazel.de> writes:
> 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
This seems like a reasonable policy skeleton. As for $age_criteria,
I'd personally be satisfied with your option (e), which I'd rephrase
slightly as
If the expected PG major version release date is after the end of
maintenance support for an LTS distribution, that OS version does
not need to be supported.
Given your rule (2), we'd still be on the hook to maintain back-branch
support for an EOL'd OS for five years, so I don't think that we need
to make the master-branch $age_criteria account for "extended
lifecycle".
In the context of RHEL, it says here [1] that RHEL8 maintenance
support runs through May 2029 while extended support runs through
May 2031. That would still mean we're supporting RHEL8 for another
four years. I'm not sure what the corresponding dates are for
other LTS vendors.
regards, tom lane
[1] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle
