incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Goffinet>
Subject Re: release policy
Date Fri, 08 Jan 2010 21:43:27 GMT
We maintain our own branch, but we have been good about rebasing changes
from 05 branch for last 2 months. We don't have major changes in our branch
(besides debian pkg and few custom Comparators and EndpointSnitches that
apply to our infrastructure) so the process has been fairly streamlined.
Internally we try to release as quickly as possible. We have experimental,
testing and prod clusters. We haven't been touching prod for awhile as we
gear up for a big Digg release with > 0.5.  We are now working on getting
trunk built in experimental and begin testing this weekend. We typically
apply patches before they even release 05/trunk and test in
experimental/testing direct from JIRA.

Once we go live with our big release, we've discussed using this exact
process to go from experimental, to testing to production. Obviously major
changes are going to require much more planning. It helps that we run in
multiple datacenters for some of these upgrades. Network changes that
require an entire cluster restart are going to be painful. We are hoping to
get some of the new SSTable changes in before our big release.

I agree with Jonathan's outline above for versioning.

On Fri, Jan 8, 2010 at 12:21 PM, Eric Evans <> wrote:

> On Fri, 2010-01-08 at 13:47 -0600, Jonathan Ellis wrote:
> [ ... ]
> > Thoughts?  (Separate threads to follow re "the next major release
> > after 0.5 specifically," and "1.0.")
> I'd be curious to hear from the Digg guys. My understanding is that
> they've been doing a considerable amount of custom release work,
> backporting patches into snapshots and the like. Is that still true?
> What would it take to remain more in-sync cassandra releases?
> --
> Eric Evans

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message