incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: release policy
Date Mon, 11 Jan 2010 18:15:32 GMT
On Mon, Jan 11, 2010 at 12:03 PM, Ryan King <> wrote:
> Both of the above are fine. I think we could even tolerate having to
> run an upgrade tool with a node, as long as we can do it one at a time
> and as long as...
>>  (3) network compatibility (from one cluster node to another): may
>> change.  If it does, we will notify you in NEWS.txt that you need to
>> upgrade the whole cluster at once, as was the case for 0.4 -> 0.5.
> ...the network compat doesn't change at the same time. If both the
> disk format and network protocol change in the same release, we can't
> easy do a rolling restart/upgrade.
> In general, doing full cluster upgrades at once is going to be
> prohibitively difficult for us. In addition to the disruption it would
> cause for clients, we wouldn't want to throw away all of our
> in-process caches at once.

I'd be comfortable committing to not breaking net compatibility in the
same release as one that needs an upgrade tool to run on the data.  I
don't think we can freeze the network protocol entirely yet.

> If we want the flexibility of changing the internal network protocol,
> we should move towards an rpc framework that can tolerate upgrades.

Thrift is supposed to tolerate upgrades... *cough* :)


View raw message