curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [VOTE] Release Apache Curator version 2.8.0
Date Fri, 08 May 2015 18:18:21 GMT
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