On Jul 3, 2009, at 7:28 PM, Chris Anderson wrote:
On Sat, Jul 4, 2009 at 1:21 AM, Noah Slater<[email protected]> 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<[email protected]>
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
