From dev-return-4989-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Jul 06 20:06:11 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 42757 invoked from network); 6 Jul 2009 20:06:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Jul 2009 20:06:10 -0000 Received: (qmail 62888 invoked by uid 500); 6 Jul 2009 20:06:20 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 62814 invoked by uid 500); 6 Jul 2009 20:06:20 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 62804 invoked by uid 99); 6 Jul 2009 20:06:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2009 20:06:20 +0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.68.5.15] (HELO relay01.pair.com) (209.68.5.15) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 06 Jul 2009 20:06:09 +0000 Received: (qmail 2011 invoked from network); 6 Jul 2009 20:05:47 -0000 Received: from 75.143.234.216 (HELO ?192.168.1.197?) (75.143.234.216) by relay01.pair.com with SMTP; 6 Jul 2009 20:05:47 -0000 X-pair-Authenticated: 75.143.234.216 Message-Id: <2D2BDA8C-DB45-4BDB-B754-4D9B9630EC49@apache.org> From: Damien Katz To: dev@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Timetable for 0.10.0 Date: Mon, 6 Jul 2009 16:05:47 -0400 References: <3418A46D-FE98-4782-9D5A-D45DE1FD899D@apache.org> <20090703232147.GC7898@tumbolia.org> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org 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: https://wiki.ubuntu.com/TimeBasedReleases 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. -Damien > > 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, http://tumbolia.org/nslater >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io