couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [DISCUSS] Goals for 2013
Date Thu, 07 Mar 2013 11:45:28 GMT

On Mar 7, 2013, at 12:04 , Dirkjan Ochtman <> wrote:

> (warning, grumpy rant forthcoming...)


understood, loud and clear. And I think we all agree with you :)

In fact, we made a few changes to the way we manage the code and releases
to improve all of that, but I think we failed at communicating this clearly.

1.3.0 will be the last of the traditional “random” releases of CouchDB.

We are switching to time based releases and aim to release a new version
of CouchDB every three months for feature releases and every month, if
we can manage, for bugfix releases. This has a few consequences:

 - Moar releases.
 - Smaller releases, upgrades will be more straightforward as differences
   will be smaller.
 - New features, when merged into master will at most sit 90 days on the
   shelf before hitting a release.
 - Bugfixes get out even faster.

We’ve written this up with more details on the wiki:


To allow for this, we had to streamline the release process, unfortunately
that has taken longer than expected, but Noah made good progress.

The test suite is still a place of contention, and if you would like to
help resolving this, please speak up.

* * *

Just to be clear, I am not trying to defend the status quo, I agree it sucks.

I just wanted to highlight the things we started doing to resolve this and
I realise that it is a bit of a mistake to have communicated this earlier.


> On Wed, Mar 6, 2013 at 7:14 PM, Noah Slater <> wrote:
>> Thoughts?
> It seems to me that a lot of this hinges on releases. Releases
> generate publicity and therefore developer interest, thus developer
> engagement. Releases make sure that work developers do gets into
> user's hands soon.
> CouchDB, and I am sorry to have been banging this drum for a few years
> now, is the worst open source project at doing releases I know.
> Here's a quote from this list, from February 13:
>> I plan to cut a release candidate from the 1.3.x branch this weekend.
> And another, from Nov 13:
>> when we set out to ship 1.3.0, we thought the cors and docs
>> branches were just around the corner. That was a couple of
>> weeks ago. We are just starting with this, but the whole
>> idea of time-based releases is that we do not wait for
>> feature branches to be ready.
>> I’d like to propose that we ignore everything we’ve said
>> before and do the following:
>> - ship 1.3.0 as reflected in the 1.3.x branch now.
> Here's another, from October 23:
>> It's been a while since we released and I want to change this now. I
>> propose making a 1.3.x branch from today's master
>> (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there.
> Another, from June 16:
>> 1. We'd like to proposed formal time-based releases
> Et cetera. As an example, the EventSource bits, which are actually
> something which would be very useful for us at work, were committed to
> the tree on May 16. They are yet to be released.
> I feel a bit hypocritical for saying all this, since I don't
> contribute much to core CouchDB (although I did do a bunch of the doc
> conversion, try to be helpful around the edges and maintain
> couchdb-python). The reason for this is mostly that I thoroughly
> dislike Erlang as a language, and have no intention of learning it
> just to help out with CouchDB. I did some Futon work back in the day,
> but had lots of trouble getting it committed since no one's really
> owned Futon for a while (and right now, it looks like other people
> have that bit covered, though they're using a modern but also quite
> complex development stack that will make it unlikely for a lowly
> back-end web developer dude like me to be able to contribute much).
> So, IMNSH and annoyingly harsh O, stop talking so much about how to
> energize the project, and Just. Ship. It. Every month, preferably. Fix
> the test suite and whatever else makes it so damn hard to release.
> Insert story here about that dude who realized people were trying to
> fix the wrong problem [1].
> End of rant, cheers,
> Dirkjan
> [1]

View raw message