Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Does compatibility between versions also mean binary compatibility?


Copy link to this message
-
Re: Does compatibility between versions also mean binary compatibility?
Yes it's already too late for 0.94.

Stack is fixing the Ref Guide about 0.92 and 0.94 being "interface
compatible": http://hbase.apache.org/book.html#upgrade0.94

We could add a new column in the release testing matrix to add versions
that we binary-tested, at least for the user-facing methods.

Also, we should have some sort of automated tool to check this. Stack and I
shared a few ideas, I'm opening a jira about it in a moment.

J-D
On Thu, Apr 4, 2013 at 3:59 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> I agree we need both, but I'm afraid that ship has sailed.
> It's not something we paid a lot of attention to especially being
> forward-binary-compatible. I would guess that there will be many more of
> these issues.
>
> Also, we have to qualify this statement somewhere. If you extend
> HRegionServer you cannot expect compatibility between releases. Of course
> that is silly, but it serves the point I am making.
>
> For client visible classes (such as in this case) we should make it work,
> we identifies issues with Filters and Coprocessors in the past and kept
> them binary compatible on a best effort basis.
>
>
> TL;DR: Let's fix this issue, and be wary of more such issues.
>
>
> -- Lars
>
>
>
> ________________________________
>  From: Andrew Purtell <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Thursday, April 4, 2013 3:21 PM
> Subject: Re: Does compatibility between versions also mean binary
> compatibility?
>
> "Compatible" implies both to my understanding of the term, unless
> qualified.
>
> I don't think we should qualify it. This looks like a regression to me.
>
>
> On Thu, Apr 4, 2013 at 1:20 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
> >wrote:
>
> > tl;dr should two compatible versions be considered both wire and
> > binary compatible or just the former?
> >
> > Hey devs,
> >
> > 0.92 is compatible with 0.94, meaning that you can run a client for
> > either against the other and you can roll restart from 0.92 to 0.94.
> >
> > What about binary compatibility? Meaning, can you run user code
> > compiled against 0.92 with 0.94's jars?
> >
> > Unfortunately, the answer is "no" in this case if you invoke setters
> > on HColumnDescriptor as you'll get:
> >
> > java.lang.NoSuchMethodError:
> > org.apache.hadoop.hbase.HColumnDescriptor.setMaxVersions(I)V
> >
> > HBASE-5357 "Use builder pattern in HColumnDescriptor" changed the
> > method signatures by changing "void" to "HColumnDescriptor" so it' not
> > the same methods anymore.
> >
> > I don't think we really had talks about binary compatibility before so
> > this is why I'm raising it up now.
> >
> > Should "compatible" versions be just wire compatible or both wire and
> > binary compatible? The latter means we need new tests. I think it
> > should be both.
> >
> > What do you guys think?
> >
> > J-D
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB