On Mon, Feb 13, 2012 at 1:02 PM, Jimmy Xiang <[email protected]> wrote: > I posted the proposal on wiki: > > http://wiki.apache.org/hadoop/Hbase/HBaseWireCompatibility >
Looks great. Looking at Phase 1, we're talking about a big bang where we shut down cluster and come up on the new stuff w/ the new stuff migrating old formats to new; e.g. the content in .META. When are we thinking we can take on the big bang? Looking at phase 2, it looks like another big bang (should phase 1 and phase 2 big bangs happen at same time)? Should we swat team it? Go away for a weekend and bang it out? Can we make issues for each of the steps so we can discuss a bit of detail on each of the bullets? On: - Should pluggable encodings (thrift/avro/pb/writable) be in scope? I'd say no. On: - Should async IO servers and clients be in scope or not? I'd say no for now. On: - What is the policy for existing versions (89, 90, 92, 94) -- do we support them or require on major upgrade before they get this story? I'm not sure how else to do it. How do you make an old client work against the new stuff? On: - Developers should be able to remove deprecated methods or arguments to maintain flexibility, but can't do that within the compatibility window. What should be our compatibility window? 2 years (roughly 4 major versions)? Which compatibility window are you referring too? Moving up on to this platform will be the singularity across nothing can cross, right? On: - What is the ZK version interoperability story? We need 3.4.x to support security. On: - What is the HDFS version interoperability story? None or at least out of scope for this project. Its another project? On: - Should architectural-level changes require a major version bump? This is an interesting one. For example, say we wanted to purge the -ROOT- region. Well, that'd be something an old client could not tolerate. So, you'd up the rpc version or figure how to purge -ROOT- in a way that old clients can still work (then there is no need to change rpc version -- to do a major version bump). St.Ack
