On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote: > 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.
Ok, I see. Yes, that makes a lot of sense :) > 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 What do you mean exactly with next-but-one LTS release? Do you intend to have two offer LTS releases in parallel? Or will there only ever be one LTS release at a time (I would prefer this)? Don't you think 6 years in total lifetime for an LTS is a bit much? The wording "at least 4 years" combined with "at least until next LTS" is a bit confusing. Which of these guidelines takes precedence? Did you intend to write "at most" for one or both of these guidelines? > 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. I think many of our users would appreciate such a scheme since it provides a mix of new features vs long-term stability.
