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 <[EMAIL PROTECTED]> wrote: Sean
On Wed, Apr 23, 2014 at 10:47 AM, Sean Busbey <[EMAIL PROTECTED]> wrote:
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.
I suspect it was after the extended conversation about dumping mock in favor of always using MAC. On Wed, Apr 23, 2014 at 11:28 AM, Keith Turner <[EMAIL PROTECTED]> wrote: Sean
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext