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 >
