cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Kutcharian <>
Subject Re: major version release schedule
Date Sat, 24 Dec 2011 19:41:30 GMT
I think there are couple of different ideas here at play

1) Time to release

2) Quality of the release

IMO, the issue that effects most people is the quality of the release. So when someone says
that we should slow down the release cycles, I think what they mean is that we should spend
more time improving the quality of the releases. Now if there is a process that can ensure
the quality of the release, specially the newly added features, I don't think anyone would
complain about have quick releases.

-- Drew

On Dec 20, 2011, at 4:15 PM, Peter Schuller wrote:

>> Until recently we were working hard to reach a set of goals that
>> culminated in a 1.0 release.  I'm not sure we've had a formal
>> discussion on it, but just talking to people, there seems to be
>> consensus around the idea that we're now shifting our goals and
>> priorities around some (usability, stability, etc).  If that's the
>> case, I think we should at least be open to reevaluating our release
>> process and schedule accordingly (whether that means lengthening,
>> shorting, and/or simply shifting the barrier-to-entry for stable
>> updates).
> Personally I am all for added stability, quality, and testing. But I
> don't see how a decreased release frequency will cause more stability.
> It may be that decreased release frequency is the necessary *result*
> of more stability, but I don't think the causality points in the other
> direction unless developers ship things early to get it into the
> release.
> But also keep in mind: If we reach a point where major users of
> Cassandra need to run on significantly divergent versions of Cassandra
> because the release is just too old, the "normal" mainstream release
> will end up getting even less testing.
> -- 
> / Peter Schuller (@scode,

View raw message