OK - Clirr is integrated and pushed. You now see Clirr messages on compile and a report is built and added to the doxia site. Unfortunately, it can’t handle the Shaded RPC jar. I (or others) can work on this later.
After reverting CURATOR-186, the Clirr report is now clear. I’ll start a new release. -Jordan On May 8, 2015 at 1:18:59 PM, Sean Busbey ([email protected]) wrote: One of my TODOs is adding pull request support, so Curator would give me good motivation to get that working. It should be easy, because I can just add ".patch" to any PR url to get a git patch file. So long as having judgement go to the Jira instead of to the PR itself, it'll be low-effort on my part. I don't have any specific gripe with Clirr; I just know that compatibility checking is a hard problem and I've already done the work needed to trust the Java API Compliance Checker. The JACC also has good support for defining a subset of classes as "the public API". They added the ability to scope to a set of annotations at the request of HBase and it's made things super easy to configure and keep up to date with what's in/out of scope. On Fri, May 8, 2015 at 11:14 AM, Mike Drob <[email protected]> wrote: > Curator uses pull requests, not patches on JIRA issues like Hadoop does. > Not sure if that distinction is relevant. > > Why don't you trust Clirr? I personally haven't run it, but I expect it to > produce the same output, although possibly formatted differently. > > On Fri, May 8, 2015 at 1:10 PM, Sean Busbey <[email protected]> wrote: > >> I'm in process of adding the java api compliance checker (which I trust >> more than Clirr) to the Hadoop Pre-commit Patch Tester. (which is a set up >> made to work with other projects via ASF jenkins). >> >> Curator could rely on that instead of coming up with its own process. >> >> On Fri, May 8, 2015 at 10:55 AM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> Even better. The Clirr plugin can do this for us as part of building. >>> I’ll incorporate it. >>> >>> http://mojo.codehaus.org/clirr-maven-plugin/ >>> >>> >>> >>> On May 8, 2015 at 12:27:27 PM, Jordan Zimmerman ( >>> [email protected]) wrote: >>> >>> I’ll take a stab at the script given your description below. You can >>> modify later. >>> >>> Thank you. >>> >>> >>> >>> On May 8, 2015 at 12:26:44 PM, Mike Drob ([email protected]) wrote: >>> >>> Just to set expectations, I'm not sure I'll have time for this today. >>> This release might still have to have manual checking, unless you're >>> willing to wait until next week. >>> >>> On Fri, May 8, 2015 at 12:20 PM, Jordan Zimmerman < >>> [email protected]> wrote: >>> I’d really appreciate the script. I can then add it to the wiki as a >>> step in the release process. >>> >>> >>> >>> On May 8, 2015 at 12:19:16 PM, Mike Drob ([email protected]) wrote: >>> >>> All of the steps are currently manual. I can take some time to automate >>> them and submit a PR with a script in dev-tools folder. >>> >>> The general process is: >>> 1. git checkout refs/tags/apache-curator-OLD >>> 2. mvn clean package -DskipTests >>> 3. mv **/*.jar ../OLD >>> >>> Repeat same steps for new. >>> >>> Compare each jar pairwise: >>> >>> for i in OLD/*; do f=`basename $i | sed -e 's/[0-9].//g' -e 's/-jar//'` >>> ; japi-compliance-checker OLD/${f}-OLD.jar NEW/${f}-NEW.jar; done >>> >>> replacing OLD and NEW as appropriate with the version numbers. The >>> output will be in the compat_reports directory. >>> >>> >>> This will check for backward compatibility. To check forward >>> compatibility (e.g. 2.7.1 -> 2.7.2), then run it with OLD and NEW reversed. >>> >>> >>> Mike >>> >>> >>> On Fri, May 8, 2015 at 12:03 PM, Jordan Zimmerman < >>> [email protected]> wrote: >>> Mike, >>> >>> Do you manually run the compliance checker on each JAR or do you have a >>> script? If you have a script, please share and I’ll put it on the wiki. >>> >>> -Jordan >>> >>> >>> >>> On May 7, 2015 at 6:31:50 PM, Mike Drob ([email protected]) wrote: >>> >>> I'm using the java-api-compatibility-checker [1] >>> >>> I think I ran into a bug with it, so I had to run using Java 7 instead of >>> Java 8, but that probably does not affect the results. >>> >>> At a minimum, it should be possible to convert JsonNode -> String -> >>> (other) JsonNode, for both directions. I'm not sure that is desirable >>> when >>> the stated intent was for performance reasons, though. >>> >>> [1] https://github.com/lvc/japi-compliance-checker/ >>> >>> On Thu, May 7, 2015 at 4:29 PM, Cameron McKenzie <[email protected] >>> > >>> wrote: >>> >>> > Good pickup Mike, >>> > What is the tool that you're using to detect this incompatibilities? It >>> > would be good for someone to run it on pull requests prior to them >>> being >>> > merged to the master branch. >>> > >>> > I'm not familiar with the x-discovery stuff, so I can't really comment >>> on >>> > whether there's a way of doing the change without breaking >>> compatibility. >>> > Is it possible to create a org.codehaus.jackson.JsonNode from a >>> > com.fasterxml.jackson.databind.JsonNode? >>> > Not easily I imagine. >>> > >>> > I agree though that we should be moving this to 3.0.0 if we cannot >>> make the >>> > change without breaking compatibility. >>> > cheers >>> > >>> > >>> > >>> > On Thu, May 7, 2015 at 10:41 AM, Mike Drob <[email protected]> >>> wrote: >>> > >>> > > -1 non-binding >>> > > >>> > > We break backward compatibility in this release. Here are reports >>> run via >>> > > the java-api-compliance-checker: >>> > > >>> > > >>> > >>> http://people.apache.org/~mdrob/curator-2.8.0/x-discovery-server-back.html >>> > > http://people.apache.org/~mdrob/curator-2.8.0/x-rpc-back.html >>> > > >>> > > The rest of the modules came up clean. >>> > > >>> > > The changes in the discovery server came from CURATOR-186. User code >>> with >>> > > references to DiscoveryContext is going to end up broken at both the >>> > source >>> > > and binary levels. >>> > > >>> > > I think the rpc changes are all a result of the same JIRA removing >>> the >>> > > jackson dependency. >>> > > >>> > > To address this, we can revert this change, and re-apply it for the >>> 3.0 >>> > > release. >>> > > >>> > > Mike >>> > > >>> > > >>> > > >>> > > On Wed, May 6, 2015 at 1:24 AM, Ashish <[email protected]> >>> wrote: >>> > > >>> > > > +1 (non-binding) >>> > > > >>> > > > Ran the build and test cases, work good >>> > > > >>> > > > On Wed, May 6, 2015 at 6:05 AM, Jordan Zimmerman < >>> [email protected]> >>> > > > wrote: >>> > > > > Hello, >>> > > > > >>> > > > > This is the vote for Apache Curator version 2.8.0 >>> > > > > >>> > > > > *** Please download, test and vote within approx. 72 hours >>> > > > > >>> > > > > Note that we are voting upon the source (tag) and binaries are >>> > > > > provided for convenience. >>> > > > > >>> > > > > Link to release notes: >>> > > > > >>> > > > >>> > > >>> > >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314425&version=12329300 >>> >>> > > > > >>> > > > > Staging repo: >>> > > > > https://dist.apache.org/repos/dist/dev/curator/2.8.0 >>> > > > > >>> > > > > Binary artifacts: >>> > > > > >>> > > > >>> > > >>> > >>> https://repository.apache.org/content/repositories/orgapachecurator-1011/ >>> > > > > >>> > > > > The tag to be voted upon: >>> > > > > >>> > > > >>> > > >>> > >>> https://git-wip-us.apache.org/repos/asf?p=curator.git;a=tag;h=22a045c39e08f10273b057c384c62db2337edac8 >>> >>> > > > > >>> > > > > Curator's KEYS file containing PGP keys we use to sign the >>> release: >>> > > > > http://www.apache.org/dist/curator/KEYS >>> > > > > >>> > > > > [ ] +1 approve >>> > > > > [ ] +0 no opinion >>> > > > > [ ] -1 disapprove (and reason why) >>> > > > >>> > > > >>> > > > >>> > > > -- >>> > > > thanks >>> > > > ashish >>> > > > >>> > > > Blog: http://www.ashishpaliwal.com/blog >>> > > > My Photo Galleries: http://www.pbase.com/ashishpaliwal >>> > > > >>> > > >>> > >>> >>> >>> >> >> >> -- >> Sean >> > > -- Sean
