incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Timetable for 0.10.0
Date Mon, 06 Jul 2009 20:05:47 GMT

On Jul 3, 2009, at 7:28 PM, Chris Anderson wrote:

> 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.

What Chris said.

There is a lot of opioni from other open source projects, including  
Ubuntu, that time-based releases are more productive than feature  
based releases:

I think feature based releases make more sense early in a project,  
when core features are still undone and the api is changing rapidly.

But I think we are stable and large enough to warrant date-based  
releases. Especially since we now many people are working concurrently  
on the code base. Delaying the release because a feature isn't ready  
means users have to choose between old code and apis, or potentially  
unstable features and apis. Time based releases also means new code  
get tested sooner in real world conditions, which helps improve the  
quality of the trunk too.


> 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