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. 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 <bus...@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.new...@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 <bus...@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
