On Tue, Dec 31, 2024 at 07:36:23AM -0500, Andrew Dunstan wrote:
> On 2024-12-30 Mo 9:00 PM, Tom Lane wrote:
> > Yeah, I can't see extending it, at least not under our current theory
> > of back-patching (nearly) every bug fix to all supported branches.
> > Could there be an intermediate state where older branches get only
> > "critical" fixes? (Security and data-loss bugs only, IMV.) Another
> > not-necessarily-exclusive idea is to designate only certain branches
> > as LTS. We could free up the developer bandwidth needed for LTS
> > by shortening the period in which non-LTS branches get full support.
>
>
> How would that work? Something like even numbered branches are LTS and odd
> numbered branches would expire after two years instead of five? Trying to
> get my head around what if any buildfarm changes that might require.
> Probably just adjust how we manage branches_of_interest.txt, but maybe
> there's something I haven't thought of.
Ubuntu does LTS every two years but has three releases in between.
Since we have yearly releases, an LTS every two years only cuts our
backpatches in half so it doesn't seem worth it.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
