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: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=OL9JLPAldJ78XC53Ky4npVjDgBZJkHb4yrtaPb1d+lnKmJHNNDJpyIKIZJ29xIoaffomeSRqeNq3q+niO0BGm15rwdLRTc5/O7q0jZ3z1wsalnmlMZYSJOCGZUEa99e3010Ea7KrNMyDK8TFnlevklgtIOybj/ZRRnPsYwyOmnA=;
References: 
 <CAGpTDNetMR+w_Yw+b5VMRYT2danW3_jUmEOnp1hrGYaUm5-uYw@mail.gmail.com>
 <CA+RK=_B42Pd5apCtQEmPJKtsm_CX_vhq8ddi+p+5hLNJTCf1AQ@mail.gmail.com>
Message-ID: <1365116380.3051.YahooMailNeo@web140605.mail.bf1.yahoo.com>
Date: Thu, 4 Apr 2013 15:59:40 -0700 (PDT)
From: lars hofhansl <larsh@apache.org>
Reply-To: lars hofhansl <larsh@apache.org>
Subject: Re: Does compatibility between versions also mean binary
 compatibility?
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CA+RK=_B42Pd5apCtQEmPJKtsm_CX_vhq8ddi+p+5hLNJTCf1AQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="1254654340-2006980737-1365116380=:3051"

--1254654340-2006980737-1365116380=:3051
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I agree we need both, but I'm afraid that ship has sailed.=0AIt's not somet=
hing we paid a lot of attention to especially being forward-binary-compatib=
le. I would guess that there will be many more of these issues.=0A=0AAlso, =
we have to qualify this statement somewhere. If you extend HRegionServer yo=
u cannot expect compatibility between releases. Of course that is silly, bu=
t it serves the point I am making.=0A=0AFor client visible classes (such as=
 in this case) we should make it work, we identifies issues with Filters an=
d Coprocessors in the past and kept them binary compatible on a best effort=
 basis.=0A=0A=0ATL;DR: Let's fix this issue, and be wary of more such issue=
s.=0A=0A=0A-- Lars=0A=0A=0A=0A________________________________=0A From: And=
rew Purtell <apurtell@apache.org>=0ATo: "dev@hbase.apache.org" <dev@hbase.a=
pache.org> =0ASent: Thursday, April 4, 2013 3:21 PM=0ASubject: Re: Does com=
patibility between versions also mean binary compatibility?=0A =0A"Compatib=
le" implies both to my understanding of the term, unless=0Aqualified.=0A=0A=
I don't think we should qualify it. This looks like a regression to me.=0A=
=0A=0AOn Thu, Apr 4, 2013 at 1:20 PM, Jean-Daniel Cryans <jdcryans@apache.o=
rg>wrote:=0A=0A> tl;dr should two compatible versions be considered both wi=
re and=0A> binary compatible or just the former?=0A>=0A> Hey devs,=0A>=0A> =
0.92 is compatible with 0.94, meaning that you can run a client for=0A> eit=
her against the other and you can roll restart from 0.92 to 0.94.=0A>=0A> W=
hat about binary compatibility? Meaning, can you run user code=0A> compiled=
 against 0.92 with 0.94's jars?=0A>=0A> Unfortunately, the answer is "no" i=
n this case if you invoke setters=0A> on HColumnDescriptor as you'll get:=
=0A>=0A> java.lang.NoSuchMethodError:=0A> org.apache.hadoop.hbase.HColumnDe=
scriptor.setMaxVersions(I)V=0A>=0A> HBASE-5357 "Use builder pattern in HCol=
umnDescriptor" changed the=0A> method signatures by changing "void" to "HCo=
lumnDescriptor" so it' not=0A> the same methods anymore.=0A>=0A> I don't th=
ink we really had talks about binary compatibility before so=0A> this is wh=
y I'm raising it up now.=0A>=0A> Should "compatible" versions be just wire =
compatible or both wire and=0A> binary compatible? The latter means we need=
 new tests. I think it=0A> should be both.=0A>=0A> What do you guys think?=
=0A>=0A> J-D=0A>=0A=0A=0A=0A-- =0ABest regards,=0A=0A=A0  - Andy=0A=0AProbl=
ems worthy of attack prove their worth by hitting back. - Piet Hein=0A(via =
Tom White)
--1254654340-2006980737-1365116380=:3051--