hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Binary API compatibility is not a requirement for any 0.98 release candidate
Date Tue, 04 Feb 2014 23:27:34 GMT
I was going to roll a new RC now that the tag compression fix was in. No problem to wait for
these if they are going in today. 


> On Feb 4, 2014, at 3:22 PM, Enis Söztutar <enis.soz@gmail.com> wrote:
> 
> We need a new RC anyway it seems. I say we fix HBASE-10460 and the HTD issues in the
new RC and be at least do best effort thing. I guess we can get both of these committed today.

> 
> Enis
> 
> 
>> On Tue, Feb 4, 2014 at 3:17 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>> 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
>> > >
>> >
> 

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message