Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of yuzhihong@gmail.com
 designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADcMMgFYLc=R2bmdLh-iK8udqgguOX0N2KLw5JKpWT8Z_j8NFg@mail.gmail.com>
References: 
 <CAOmV22v2bBy7mHopMENqg2LyQoKvgfQKWSF17MRy9y8CYk2ung@mail.gmail.com>
	<CALte62wychtmpeLhVu7__pgY3x_902a8axK=_b-eh=ejH_6A1Q@mail.gmail.com>
	<CAOmV22v7KSnx+wNrExBUSdOBjZ_og9N+-q0p7f8BcJnPDZhtfg@mail.gmail.com>
	<CADcMMgFYLc=R2bmdLh-iK8udqgguOX0N2KLw5JKpWT8Z_j8NFg@mail.gmail.com>
Date: Mon, 13 Feb 2012 16:15:07 -0800
Message-ID: 
 <CALte62zd2Zus3P0iB_xNJeGGkBEQvHBSr1h-iitqzBRxZ1iy-A@mail.gmail.com>
Subject: Re: HBase wire compatibility
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=0016e6dd8d17c8147e04b8e17c3a

--0016e6dd8d17c8147e04b8e17c3a
Content-Type: text/plain; charset=ISO-8859-1

bq. Should we swat team it?

Or do this at the next Hackathon.

On Mon, Feb 13, 2012 at 4:09 PM, Stack <stack@duboce.net> wrote:

> On Mon, Feb 13, 2012 at 1:02 PM, Jimmy Xiang <jxiang@cloudera.com> 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
>

--0016e6dd8d17c8147e04b8e17c3a--