incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan King <r...@twitter.com>
Subject Re: release policy
Date Mon, 11 Jan 2010 18:17:41 GMT
On Mon, Jan 11, 2010 at 10:15 AM, Jonathan Ellis <jbellis@gmail.com> wrote:
> On Mon, Jan 11, 2010 at 12:03 PM, Ryan King <ryan@twitter.com> 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.

Good.

>> 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* :)

*cough* Avro *cough*.

-ryan

Mime
View raw message