Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates
 209.85.213.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <63757E38-CAB8-4C7D-8854-83B77B3A3E32@gmail.com>
References: 
 <CA+RK=_C8=Cg450Gr+ZAQ54Fp3vEn-OWgV7Mg8iXFM6zTHZ3B6Q@mail.gmail.com>
	<1391492784.11817.YahooMailNeo@web140601.mail.bf1.yahoo.com>
	<CAAha9a0u73Sgpu_V47rj-h5Kkcr-KLESmR42G8EmC4dC4DJZUQ@mail.gmail.com>
	<63757E38-CAB8-4C7D-8854-83B77B3A3E32@gmail.com>
Date: Tue, 4 Feb 2014 15:17:42 -0800
Message-ID: 
 <CALte62xg3K9G+PN0n39BA74yS0YaNGyWr+ywrB5TC+Gcb+wWbg@mail.gmail.com>
Subject: Re: Binary API compatibility is not a requirement for any 0.98
 release candidate
From: Ted Yu <yuzhihong@gmail.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: Jonathan Hsieh <jon@cloudera.com>, lars hofhansl <larsh@apache.org>,
	Andrew Purtell <apurtell@apache.org>
Content-Type: multipart/alternative; boundary=20cf3010eaa1d9aba904f19cd822

--20cf3010eaa1d9aba904f19cd822
Content-Type: text/plain; charset=ISO-8859-1

The other issue Alex reported doesn't need to be fixed because
HTableDescriptor is marked @InterfaceStability.Evolving, right ?


On Tue, Feb 4, 2014 at 3:13 PM, Andrew Purtell <andrew.purtell@gmail.com>wrote:

> I am not arguing the minor patches in question. Put them in. What I am
> saying is voting -1 on a release because of binary compatibility issues
> misses the earlier discussion where the consensus was not to do that.
>
> > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jon@cloudera.com> wrote:
> >
> > Andrew,
> >
> > I basically agree with lars here -- the ship has sailed here. However,
> there are some patches that restored binary compat in places committed to
> 0.98 already.  (IMO actually this would be an argument to fork earlier in
> the future)
> >
> > I have some comments on HBASE-10460.  Specifically it is on a class that
> is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think
> they fix there should get into 0.98.
> >
> > Jon.
> >
> >
> >
> >> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <larsh@apache.org> wrote:
> >> My $0.02...
> >>
> >> Wire (client-server and server-server) compatibility is a must have.
> >> Binary compatibility should be a best effort. I.e. we shouldn't go out
> of our way to break things, but if we want to clean up an API we should do
> that.
> >> So much for 0.98.
> >>
> >> Going forward...
> >>
> >> Once we go past version 1.0 and to semantic versioning this will need a
> bigger discussion.
> >>
> >> As discussed in the past there are at least four angles here:
> >> 1. Client-server wire compatibility
> >> 2. Server-server wire compatibility
> >> 3. Client binary compatibility
> >> 4. Server interface binary compatibility (for coprocessors)
> >>
> >> #4 is surprisingly important as it basically turns into a #1 problem
> when a project ships with coprocessors.
> >>
> >> Then we need to define compatibility rules for major/minor/patch
> versions.
> >> In the last PMC meeting we had a start on this. We need to finish the
> details.
> >>
> >> -- Lars
> >>
> >>
> >> ----- Original Message -----
> >> From: Andrew Purtell <apurtell@apache.org>
> >> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
> >> Cc:
> >> Sent: Monday, February 3, 2014 3:08 PM
> >> Subject: Binary API compatibility is not a requirement for any 0.98
> release candidate
> >>
> >> If you would like to change this consensus now, we can do so, and add
> it as
> >> a release criterion. That would require undoing the comparator cleanups
> and
> >> related breaking changes that went in as HBASE-9245 and subtasks. So
> let's
> >> not. I am -1 on making a change like this late in the day, after we have
> >> already had two RCs and I am hoping to get a third out tomorrow.
> >>
> >> --
> >> Best regards,
> >>
> >>    - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // jon@cloudera.com // @jmhsieh
> >
>

--20cf3010eaa1d9aba904f19cd822--