couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <chewbra...@apache.org>
Subject Re: [RELEASE][PROPOSAL] New release schedule
Date Fri, 05 Jul 2013 17:32:01 GMT
On Thu, Jul 4, 2013 at 6:43 AM, Noah Slater <nslater@apache.org> 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 <jan@apache.org> wrote:
>
> >
> > On Jul 3, 2013, at 21:57 , Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> >
> > > On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <nslater@apache.org>
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message