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
