couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [RELEASE][PROPOSAL] New release schedule
Date Thu, 04 Jul 2013 13:43:34 GMT
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 <> wrote:

> On Jul 3, 2013, at 21:57 , Dirkjan Ochtman <> wrote:
> > On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <> 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
> --


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