[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Intentions for 1.11 release timing

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 22 Jun 2018 19:01:38 +0000

Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100:
> > > Done in http://svn.apache.org/r1834111,
> > > "Publish our new 6-month standard and 2-year LTS release schedule."
> >
> > In practical terms, we have now promised to release 1.11.0 around October, so
> > we should start thinking of cutting a 1.11.x stabilization branch around late
> > August / early September.
>
> Yup.
>
> > The new documentation states that 1.9 would be an LTS release, to be supported
> > until 1.14; I had assumed 1.10 would be an LTS release (supported until 1.14 is
> > released + overlap period)
>
> (and then supported with security/corruption fixes until 1.18 is released)
>
> > but 1.9 would be a "normal" release, to be supported
> > until 1.11 is released. That would be consistent both with the guarantees made
> > when 1.9 was released and with the new "1.x is LTS if (x%4 == 2)" practice.
>
> Previously we did not lead users to think that some releases were going
> to be supported much longer than others so it was reasonable for any
> user to choose 1.9 as the release they plan to use for a longish period
> (say 4 years) and expect it will be supported (with security/corruption
> fixes) for about that time.
>
> That is why I think we should keep the support period for 1.9 as one
> release (until 1.10) for general fixes plus 2 years (being roughly the
> same as one old release cycle period that would have been expected) for
> security/corruption fixes.
>
> Another angle on this: I interpret what we are doing as inserting extra
> mini-feature-releases into the existing cycle, rather than compressing
> the existing cycle to happen four times faster. So telling a user that
> "the next release" they were expecting is suddenly going to be a quick
> mini-release would be an unwelcome surprise in terms of support
> stability. (Hopefully at the same time a welcome surprise in other
> ways.)
>
> What do you think?

That was a very clear explanation, thanks, and it makes sense. I agree
we should keep 1.9 users' expectations in mind. I am concerned,
however, that making 1.9 LTS does mean that for the two months after
1.13's release, we'd be supporting four release lines simultaneously:
1.9, 1.10, 1.12, 1.13. Are we sure that's not more than we can chew?

I also wonder what happens if we find that our releases are spaced
further than six months apart from each other. I suppose that if our
releases turn out to be, for the sake of example, 12 months apart, we
could consider making 1.12 an LTS release and EOL'ing 1.9 at that time,
rather than upon 1.14's release. Time enough to worry about this situation
if and when it happens, I suppose.

Cheers,

Daniel
Received on 2018-06-22 21:01:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.