On Mon, Jan 11, 2010 at 10:15 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > On Mon, Jan 11, 2010 at 12:03 PM, Ryan King <r...@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
