couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Timetable for 0.10.0
Date Fri, 03 Jul 2009 23:21:47 GMT
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?

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.


Noah Slater,

View raw message