Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - Declaring HBase Public API in 0.94


Copy link to this message
-
Re: Declaring HBase Public API in 0.94
Nick Dimiduk 2013-04-16, 21:14
Aleks,

With the exception of the source paths [0], [1], I don't see anything that
needs changed for 0.94. In fact, those paths look correct for 0.94 but
wrong for trunk. I would have expected to see all of the modules broken
out. Are you sure this generates the reports you expect when run on trunk?

Thanks,
Nick

[0]:
https://github.com/apache/hbase/commit/379f88f0b55b817cfa395326d5da0e3d6552ef28#L0R38
[1]:
https://github.com/apache/hbase/commit/379f88f0b55b817cfa395326d5da0e3d6552ef28#L0R42

On Tue, Apr 16, 2013 at 1:56 PM, Aleksandr Shulman <[EMAIL PROTECTED]>wrote:

> Hello,
>
> I put together a JDiff compatibility tool that was committed to trunk.
> Would someone be kind enough to backport it into 0.94.8?
>
> Here is the commit for the tool:
>
> https://github.com/apache/hbase/commit/379f88f0b55b817cfa395326d5da0e3d6552ef28
>
> Here is the review:
> https://reviews.apache.org/r/10361/
>
> Thanks in advance,
>
> Aleks S.
>
> On Tue, Apr 9, 2013 at 10:47 AM, Aleksandr Shulman <[EMAIL PROTECTED]
> >wrote:
>
> > I put together a tool that leverages Tom White's work.
> > Here is a review for it: https://reviews.apache.org/r/10361/
> >
> > It will diff the public java api definitions of hbase in two git repos
> and
> > generate an HTML report. The tool will reside in the /dev-support folder.
> > The documentation is inline in the file.
> >
> > I'd appreciate your input in how I can make it more useful and usable for
> > us.
> >
> > Once we agree on the definitions of what classes are indeed public, we
> can
> > fine-tune this tool to ignore everything else.
> >
> > -Aleks S.
> >
> >
> > On Mon, Apr 8, 2013 at 3:55 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> >
> >> The advantage of the annotations is that Tom White already did the work
> >> for
> >> jdiff to ignore non-public classes over in Hadoop land. We could
> leverage
> >> that work, whether we re-use the o.a.h.classification annotations or add
> >> our own copies in org.apache.hbase.*.
> >>
> >> -Todd
> >>
> >> On Mon, Apr 8, 2013 at 3:08 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> >>
> >> > It seems we could just generally document that:
> >> > - no RPC incompatibilities
> >> > - no API breaking changes to any user facing classes (now we'll pay
> >> better
> >> > attention to this)
> >> > - best effort to keep coprocessor API changes backward compatible
> >> >
> >> > If - on the other hand - we wanted to automate API checks then we'd
> need
> >> > tagging (either in form of an annotation or Javadoc)
> >> >
> >> > +1 on the javadoc tagging if you're willing to take than on. As other
> >> have
> >> > said -1 on pulling Interface Audience in.
> >> > Your set of classes looks good.
> >> >
> >> > -- Lars
> >> >
> >> >
> >> >
> >> > ________________________________
> >> >  From: Elliott Clark <[EMAIL PROTECTED]>
> >> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >> > Sent: Monday, April 8, 2013 1:49 PM
> >> > Subject: Re: Declaring HBase Public API in 0.94
> >> >
> >> > Please don't pull in @InterfaceAudience.  Keeping 0.2x compatibility
> was
> >> > something that was hard won in 0.94, it would be a real shame to loose
> >> that
> >> > now.
> >> >
> >> >
> >> > On Mon, Apr 8, 2013 at 11:07 AM, Aleksandr Shulman <
> [EMAIL PROTECTED]
> >> > >wrote:
> >> >
> >> > > Hi everyone,
> >> > >
> >> > > In light of all the conversation on compatibility, I wanted to float
> >> the
> >> > > idea of documenting which Java packages, classes, and methods we
> want
> >> to
> >> > > declare as being API compatible in 0.94.x. I'd like your input on:
> >> > > 1. JavaDoc vs. using AudienceInterface
> >> > > 2. What the javadoc notation should look like
> >> > > 3. Which pieces of code should be tagged
> >> > >
> >> > > What do I mean by documenting API compatibility? That means that we
> >> > suggest
> >> > > the anyone building applications use specific methods because they
> >> would
> >> > > continue to be both binary and RPC-compatible going forward. Any
> >> > > application written, either running on a node of a cluster or on a