subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: Intentions for 1.11 release timing
Date Mon, 25 Jun 2018 10:54:16 GMT
Julian Foad wrote on Mon, 25 Jun 2018 11:31 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100:
> >> 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. [...]
> > 
> > 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 don't see any problem. Firstly, we haven't (yet) promised any overlap 
> period, although it would be unreasonable not to have any overlap so we 
> should certainly aim for something like that and maybe state it 
> explicitly. But in any case we do not promise any minimum amount of 
> support -- we do not promise to release at least N backports per release 
> line, or to backport a particular fix to every supported line within N 
> days --

Suppose a security issue is found that affects "1.9 and all later
versions", don't we (implicitly) promise that the fix therefor would be
announced for all supported release lines simultaneously?  I agree that
non-security bugfixes are backported on a "no promises (volunteer-led
project)" basis.

> so if we are struggling then the support period of one or more 
> of the older release lines will simply expire before we get around to 
> it, and that is just "tough luck" or in other words the normal operation 
> of a volunteer-led project.
> So I am not worried about that.



View raw message