Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAGHyZ6+THqa3oAbfeEmD4p6PYi0z8q9sd0_SX9mYW+Ai6Dmvqw@mail.gmail.com>
References: 
 <CAGHyZ6JrOCKC52oyJAvccAmOnUpFkrwrQiHpkDz=_wPbqEgDoQ@mail.gmail.com>
	<CADxc9Bkid3gdzWC+pf_VOLcuBvAPBr=A=uHJamrk1KBPnuETqg@mail.gmail.com>
	<CAGHyZ6JvfMaywqtxRMtimLK2ffg_z5qVp2qS7hWz8yyqe7fjpA@mail.gmail.com>
	<CAGHyZ6+THqa3oAbfeEmD4p6PYi0z8q9sd0_SX9mYW+Ai6Dmvqw@mail.gmail.com>
Date: Wed, 23 Apr 2014 11:58:41 -0400
Message-ID: 
 <CAGUtCHqiS-Gnj+-tmBDoEY9uE7jMa58fgwozjaiAHSgZbOWrzQ@mail.gmail.com>
Subject: Re: compatibility check between 1.5.x and 1.6.0?
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7b6743a27208c804f7b7cee3

--047d7b6743a27208c804f7b7cee3
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 23, 2014 at 10:47 AM, Sean Busbey <busbey@cloudera.com> wrote:

> Okay, I think all of these incompatibilities are things that should not
> have been in the public API in the first place.
>
> * client.admin.SecurityOperationsImpl
> * client.admin.TableOperationsImpl
> * client.admin.InstanceOparationsImpl
> * client.mock.MockShell
> * client.mock.MockTabletLocator
>
> These changes are due to refactorings outside of the public API leaking
> into classes within the client that handle implementation. For these
> things, I think we should fix them to not be in the public API and just
> include an apology in the release notes.
>


+1

I remember seeing the .*Impl classes and ignoring them because they were
Impl, but I shouldn't have because they are not in an impl package.   I
don't remember seeing anything about mock, I must have glossed over that.


>
> Any objections before I make a ticket and put up a patch? Do we need a vote
> about breaking the API, or is calling out that we're going to do that in
> the RC vote sufficient?
>
> (the other findings appear to be the japi compliance checker not
> recognizing a method moving up a class hierarchy)
>
>
>
> On Wed, Apr 23, 2014 at 1:27 AM, Sean Busbey <busbey@cloudera.com> wrote:
>
> > Here's the current reports, built with japi-compliance-checker 1.3.6
> >
> > http://people.apache.org/~busbey/compat_reports/accumulo/
> >
> > executed with:
> >
> > for version in 1.5.0 1.5.1 1.5.2; do japi-compliance-checker
> > -skip-deprecated -old japi-accumulo-${version}.xml -new
> > japi-accumulo-1.6.xml -l accumulo; done
> >
> > with the config xmls like what's in the repo, but set to look in my maven
> > repo and to not skip mock.
> >
> > I'll triage the 1.5.0 changes tomorrow
> >
> >
> >
> > On Tue, Apr 22, 2014 at 9:04 PM, Eric Newton <eric.newton@gmail.com
> >wrote:
> >
> >> I believe Keith did a mechanical/manual analysis and brought back a
> couple
> >> of methods/classes.
> >>
> >> -Eric
> >>
> >>
> >> On Tue, Apr 22, 2014 at 8:46 PM, Sean Busbey <busbey@cloudera.com>
> wrote:
> >>
> >> > Has anyone done a compatibility check for the public API between 1.5.x
> >> and
> >> > 1.6.0?
> >> >
> >> > While looking into ACCUMULO-2722 I noticed some changes that might be
> >> > problematic in client.mock and was wondering if anyone did a larger
> >> sweep
> >> > already.
> >> >
> >> > --
> >> > Sean
> >> >
> >>
> >
> >
> >
> > --
> > Sean
> >
>
>
>
> --
> Sean
>

--047d7b6743a27208c804f7b7cee3--