On Thu, Jul 4, 2013 at 6:43 AM, Noah Slater <[email protected]> wrote:
> Russell, I thought about padding too. But there's just no way I think I can > get it to work without putting undue stress on me, or on the community. > Padding would also mean that we were trying to do two releases at any one > point. The release who's window was about the close, and the release who's > window was a month away from starting. The only real way to add padding > would be to make the releases happen X months apart, where X is the max > value of "delay" we expect to experience. But if you look at the 1.3.0 > release, X was six months. > > So I figure that delays happen. We're a volunteer community, and sometimes > we hit a really thorny problem. The release procedure should embrace this > fact, instead of trying to paper over it. > > As with most things we do, this should a simple change that we can reverse > if it doesn't work out for us. > > Jan, agreed. We should agree on a support plan up front. > > Is this what you are suggesting: > > * N-1 for major version numbers. So if we're on 3.x, then we > will back-port to 2.x where possible. But not 1.x. > > I am not sure there's any need for LTS in that scenario. For instance, when > we bump to 2.x (hopefully this year) then we're saying, according to the > scheme above, that 1.x will be supported for 12 months. > > Is there any circumstance that would not be covered by N-1 for major > version numbers? > > Also, what do we mean by support? That we'll backport features and > bugfixes? Just bugfixes? > > I am asking from an RM point of view, because once we bump to 2.x, our > support plan will have a major impact on our release schedule. It might > mean, for instance, that for every regular release we do, we have to do a > 1.x legacy release. > > I worry that this could become burdensome Perhaps we ought to stagger it > out. So, hmm. We could do regular release every other month, and then a > support release every other month. Just alternate them. > > As long as we were only ever supporting N-1 major version numbers, this > release pattern would work for us forever. > > > On 4 July 2013 10:50, Jan Lehnardt <[email protected]> wrote: > > > > > On Jul 3, 2013, at 21:57 , Dirkjan Ochtman <[email protected]> wrote: > > > > > On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <[email protected]> > wrote: > > >> Yep. One that date we can look at master and see what we have. If we > > have > > >> any features, then we bump the minor version. If we have anything that > > >> breaks backwards compatibility, then we bump the major. > > > > > > So that means we have no guarantees of any kind on how long we go > > > between feature releases, which also means our shortest possible > > > maintenance window for old release might be something like 8-10 weeks? > > > > > > I mean, personally I'm fine with this, I always keep up to date with > > > the latest release anyway. But what you're proposing here seems like a > > > somewhat big deal for those slightly more enterprisey types who like > > > themselves some stability, instead of forcing to be upgraded to a > > > release with new features (and consequently, new bugs). > > > > We haven’t defined this properly, but we want to designate certain > > releases to be Long Term Support (LTS) releases, that are supported > > at least for a year, regardless of the N-1 support for regular > > releases. > > > > I’d say the last 1.x.y release before 2.0.0 should be our first LTS > > release. > > > > * * * > > > > +1 on Noah’s proposal. > > > > Best > > Jan > > -- > > > > > > > > > -- > NS > Thanks for the response Noah. The releases are definitely time consuming, so do what makes that the simplest and least stressful for you. +1 to your proposal. -Russell
