bq. Should we swat team it? Or do this at the next Hackathon.
On Mon, Feb 13, 2012 at 4:09 PM, Stack <[email protected]> wrote: > 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 >
