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

Switch to Plain View
HBase >> mail # dev >> Declaring HBase Public API in 0.94


+
Aleksandr Shulman 2013-04-08, 18:07
+
Elliott Clark 2013-04-08, 20:49
+
Ted Yu 2013-04-08, 21:24
+
Todd Lipcon 2013-04-08, 21:50
Copy link to this message
-
Re: Declaring HBase Public API in 0.94
> Given that it's only annotations, you also may be able to pull in the
Hadoop 2 annotations package without all of common (I believe it's a
separate maven artifact)

I fear that will cause even more problems, since 0.94 will still be run
against 0.23, and 2.x. I would vote for bringing the annotations in if we
would go that route.

Enis
On Mon, Apr 8, 2013 at 2:50 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> There's always the option of duplicating those annotations into the HBase
> package if you want to annotate 0.94 without depending on Hadoop 2.
>
> Given that it's only annotations, you also may be able to pull in the
> Hadoop 2 annotations package without all of common (I believe it's a
> separate maven artifact)
>
> -Todd
>
> On Mon, Apr 8, 2013 at 2:24 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > bq. Keeping 0.2x compatibility was something that was hard won in 0.94
> >
> > True. We should maintain this status.
> >
> > On Mon, Apr 8, 2013 at 1:49 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:
> >
> > > 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
> > remote
> > > > machine, would continue to work properly without recompile for all
> > > versions
> > > > of 0.94.x running on the cluster.
> > > >
> > > > *Benefits:*
> > > > It would prevent developers from using calls that are subject to
> > change.
> > > > This would give developers more confidence in using the platform,
> which
> > > > will encourage more development on our platform.
> > > > 0.94 will still be with us for some time and I think the
> > > > better-late-than-never approach will save us pain down the road.
> > Finally,
> > > > it would allow us to more easily verify that we are in fact API
> > > compatible.
> > > >
> > > > *Can we use AudienceInterface?*
> > > > HBase 0.94 can be compiled against both hadoop 0.2x, 1.x, and 2.0.x.
> In
> > > the
> > > > case of 0.2x, the AudienceInterface classes were not bundled.
> > Therefore,
> > > we
> > > > cannot expect HBase 0.94 to support it. For that reason, I think
> > JavaDoc
> > > > might be better.
> > > > On the other hand, perhaps we might just want to bundle
> > AudienceInterface
> > > > with 0.94 going forward? Then we can have consistent annotations in
> > 0.94,
> > > > 0.95, and 0.96 without worrying about the hadoop version.
> > > >
> > > > Please correct me if I'm wrong about any of the above.
> > > >
> > > > *Clarification of RPC compatibility:*
> > > > We care about RPC compatibility when we create clients that bundle
> > their
> > > > dependency jars with them. These jars are used to form a request that
> > is
> > > > executed on a remote machine (i.e. the cluster). If the cluster is
> > > upgraded
> > > > and no longer recognizes the command, then this will break RPC
> > > > compatibility.
> > > >
> > > > *Clarification of Binary compatibility:*
> > > > We care about binary compatibility when a client is created and
> > compiled,
> > > > and the jars on which is depends change. It should still be able to
> > form
> > > > requests using those jars. If the cluster is upgraded and the
+
lars hofhansl 2013-04-08, 22:08
+
Todd Lipcon 2013-04-08, 22:55
+
Aleksandr Shulman 2013-04-09, 17:47
+
Aleksandr Shulman 2013-04-16, 20:56
+
Nick Dimiduk 2013-04-16, 21:14
+
Aleksandr Shulman 2013-04-17, 18:01