> Stefan Sperling wrote:
>> On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
>> > Branch for stabilization 4 months after the last release (which was in 2018-04), so:
>> >
>> > * Branch in 2018-08
>> > * Aim to release in 2018-10
>>
>> Wouldn't we also have to adjust our backporting guidelines if we
>> did this?
>
> Yes, certainly we have to adjust our backporting guidelines!
>
>> Would 1.10 only receive "security or data corruption
>> fixes" as of October 2018?
>
> No, 1.10 would be designated "LTS" (long term support).
>
> Because we haven't previously told users anything, they should assume that 1.10 will be supported over a similar time scale to previous releases. Therefore we should designate 1.10 as LTS, and 1.11 as a standard (non-LTS) release.
>
> Definitions something like this:
>
> LTS release:
> * full backports for at least 2 years, and at least until the next LTS release
> * security/corruption fixes for at least 4 years, and at least until the next-but-one LTS release
Sorry, no. No one can plan with the words "at least". This isn't a
guarantee. Plus, two years isn't really longterm. I'd expect three years
and two more years for security/corruption. As soon as a new LTS release
goes GA, there will be a three months upgrade period.
> standard release:
> * full backports at least until the next standard release
> * security/corruption fixes at least until the next-but-one standard release
>
> Plus a bit extra (e.g. a couple of months) on each of these times.
Sounds better, pick your cadence (6 or 9 months) and give at least one
months overlapping.
For instance, I am stuck with RHEL for Oracle databases at work and I
hate RHEL with a passion because this stuff is already dead when it is
released. I have to compile everything myself -- what a waste of time.
Same applies to Ubuntu LTS after two years. It makes basically the
entire packaging system superfluous.
Michael
Received on 2018-05-20 13:01:06 CEST