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.
Received on 2018-05-18 16:11:38 CEST