curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: [VOTE] Release Apache Curator version 2.8.0
Date Fri, 08 May 2015 18:53:56 GMT
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 (busbey@cloudera.com) 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 <madrob@cloudera.com> 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 <busbey@cloudera.com> 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 <  
>> jordan@jordanzimmerman.com> 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 (  
>>> jordan@jordanzimmerman.com) 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 (madrob@cloudera.com) 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 <  
>>> jordan@jordanzimmerman.com> 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 (madrob@cloudera.com) 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 <  
>>> jordan@jordanzimmerman.com> 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 (madrob@cloudera.com) 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 <mckenzie.cam@gmail.com 

>>> >  
>>> 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 <madrob@cloudera.com> 

>>> 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 <paliwalashish@gmail.com>
 
>>> wrote:  
>>> > >  
>>> > > > +1 (non-binding)  
>>> > > >  
>>> > > > Ran the build and test cases, work good  
>>> > > >  
>>> > > > On Wed, May 6, 2015 at 6:05 AM, Jordan Zimmerman <  
>>> randgalt@apache.org>  
>>> > > > 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  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message