couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Timetable for 0.10.0
Date Fri, 03 Jul 2009 23:28:40 GMT
On Sat, Jul 4, 2009 at 1:21 AM, Noah Slater<> wrote:
> On Fri, Jul 03, 2009 at 12:16:55PM -0700, Chris Anderson wrote:
>> On Thu, Jul 2, 2009 at 10:45 AM, Damien Katz<> wrote:
>> > I propose Friday, July 31st as the 0.10.x branch date. I don't care that
>> > much about the exact, but I do want to pick a date and stick with it,
>> > because I don't want to get into the same situation we did with 0.9.0, where
>> > it was held up for months as we waited way too long for features I was
>> > working on. (sorry)
>> I agree with Damien here. We should schedule a release for the end of
>> the month and stick to our guns. There are lots of features that won't
>> make it into 0.10, but that's what 0.11 is for.
> Why base our releases on time?

The reason to set a date and then work toward is because this is open
source, and otherwise we are likely to end up with an indefinitely
long period while all the awesome features come in. I think what we've
done since 0.9 is nearly worthy of a new release, and setting a
deadline for the end of the month at least gets me motivated to finish
adding the features that fill out the suite of new functionality
started by _changes and the new _list API.

I think a time-based release process is healthy, as in open-source
there will never be a particular moment when all the features are
ready. As soon as one gets ready others will come along being "almost
ready" and that's how we ended up with 6 months between 0.8.1 and 0.9.

To me it just seems pragmatic. Especially if we can get the replicator
based on _changes, and then truly deprecate the update_notification
process, we'll be able to ship a version of Couch with Ubuntu that
looks a lot more like 1.0 than 0.9.x currently does.

> I don't understand the reasoning at all. It makes far more sense for us to make
> releases based on the feature lists. As a user, I want to upgrade because the
> new version provides an interesting set of new functionality and fixes.
> I really don't care about the time since my last upgrade, as long as this
> doesn't unnecessarily delay my access to crucial features. I would consider
> any delay under, say, six months to be more than acceptable.
>> The important data point here is that whatever our most stable release is at
>> the end of the month will likely be going into the Ubuntu Karmic Live CD and
>> landing on 10 million desktops. We should understand that this means we'll be
>> supporting this release for a broader user base and a longer timeframe than
>> past releases. If we don't do a release before then we'll probably see 0.9.1
>> in Ubuntu and that'd be a shame as the _list API improvements are only in
>> current trunk, _changes is new, etc.
> In reality, it has to go through me, and through Debian first. Moreover, Ubuntu
> have a number of proposed changes to the package, and I am currently talking
> with the maintainers to make sure this process goes as smooth as possible.
> Best,
> --
> Noah Slater,

Chris Anderson

View raw message