curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: [VOTE] Release Apache Curator version 2.11.0 and 3.2.0
Date Mon, 20 Jun 2016 22:04:57 GMT
Ok, I guess I'll put something in the versions section on curator.apache.org

cheers

On Tue, Jun 21, 2016 at 6:08 AM, Mike Drob <madrob@cloudera.com> wrote:

> Yea, as long as you doc it somewhere, it shouldn't be a blocker.
>
> On Sat, Jun 18, 2016 at 4:59 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
> wrote:
>
> > That's fine with me. You OK with it Mike?
> > On 19 Jun 2016 1:21 AM, "Jordan Zimmerman" <jordan@jordanzimmerman.com>
> > wrote:
> >
> > > Can we solve this at a different time? People are waiting on this
> release
> > > and the version number will not affect their applications one bit.
> > >
> > > -Jordan
> > >
> > > > On Jun 18, 2016, at 4:31 AM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > > wrote:
> > > >
> > > > I can see both points of view. In an ideal world we would use the
> > proper
> > > > definition of semantic versioning, but pragmatically, I think that it
> > is
> > > > going to be difficult to maintain with 2 concurrent sets of releases.
> > > So, I
> > > > think that we should just tried with the version numbers suggested.
> > > > Thoughts?
> > > > On 18 Jun 2016 2:09 PM, "Jordan Zimmerman" <
> jordan@jordanzimmerman.com
> > >
> > > > wrote:
> > > >
> > > >> I’m very much against bumping the major version number. We’re
using
> > the
> > > >> major version number to indicate compatibility with ZooKeeper.
> > > >> Historically, the middle number has represented API compatibility
> for
> > > >> Curator. There’s no reason to change now. We can revisit in the
> > future.
> > > >>
> > > >> -Jordan
> > > >>
> > > >>> On Jun 17, 2016, at 11:04 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com
> > > >
> > > >> wrote:
> > > >>>
> > > >>> Thanks Mike, I will rebuild and get rid of the bin and test
> > > directories.
> > > >> In
> > > >>> regards to the incompatibilities generated by clirr, what's the
go?
> > > >> Should
> > > >>> we not be making any incompatible API changes without incrementing
> > the
> > > >>> major version number? In that case I guess we need to revert that
> > > changed
> > > >>> the int to long for 2.11 but what about all the changes in 3.2
> > > presumably
> > > >>> we don't want to release a 4.0?
> > > >>> Cheers
> > > >>> -1
> > > >>>
> > > >>> Downloaded artifacts from staging repos.
> > > >>> Signatures are good.
> > > >>> Checksums are good.
> > > >>>
> > > >>> Source zips does not match tag:
> > > >>>
> > > >>> $ diff --recursive . /tmp/curator/2.11/apache-curator-2.11.0/
> > > >>> Only in /tmp/curator/2.11/apache-curator-2.11.0/curator-framework:
> > > >>> test-output
> > > >>> Only in /tmp/curator/2.11/apache-curator-2.11.0/curator-recipes:
> > > >> test-output
> > > >>> Only in .: .git
> > > >>> Only in .: .gitignore
> > > >>>
> > > >>> $ diff --recursive . /tmp/curator/3.2/apache-curator-3.2.0/
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-examples:
bin
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-framework:
> bin
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-framework:
> > > >> test-output
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-recipes:
bin
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-recipes:
> > > >> test-output
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-test: bin
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-x-discovery:
> > bin
> > > >>> Only in
> > > /tmp/curator/3.2/apache-curator-3.2.0/curator-x-discovery-server:
> > > >>> bin
> > > >>> Only in /tmp/curator/3.2/apache-curator-3.2.0/curator-x-rpc: bin
> > > >>> Only in .: .git
> > > >>> Only in .: .gitignore
> > > >>>
> > > >>> I think the .git and .gitignore difference is expected, but I
don't
> > > think
> > > >>> we should have bin or test-output directories in our source
> releases.
> > > >>>
> > > >>> Running mvn package I get a lot of warnings on 3.2 from the clirr
> > > plugin,
> > > >>> too many to list here individually. I get some in 2.11 as well,
but
> > > much
> > > >>> fewer.
> > > >>> Changing from Pathable to ErrorListenerPathable is fine for
> > > >> compatibility,
> > > >>> I think. Changing from int to long is not.
> > > >>>
> > > >>> Mike
> > > >>>
> > > >>> On Wed, Jun 15, 2016 at 7:28 PM, Jordan Zimmerman <
> > randgalt@apache.org
> > > >
> > > >>> wrote:
> > > >>>
> > > >>>> Signatures on both files match
> > > >>>>
> > > >>>> +1 Binding
> > > >>>>
> > > >>>> On Wed, Jun 15, 2016 at 3:18 AM, Cameron McKenzie
> > > >>>> <cammckenzie@apache.org> wrote:
> > > >>>>> Hello,
> > > >>>>>
> > > >>>>> This is a combined vote to release Apache Curator versions
2.11.0
> > and
> > > >>>> 3.2.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:
> > > >>>>> 2.1.11 - *
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314425&version=12335828
> > > >>>>> <
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314425&version=12335828
> > > >>>>> *
> > > >>>>> 3.2.0 - *
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314425&version=12335829
> > > >>>>> <
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314425&version=12335829
> > > >>>>> *
> > > >>>>>
> > > >>>>> Staging repos:
> > > >>>>> https://dist.apache.org/repos/dist/dev/curator/2.11.0/
> > > >>>>> https://dist.apache.org/repos/dist/dev/curator/3.2.0/
> > > >>>>>
> > > >>>>> Binary artifacts:
> > > >>>>> 2.11.0 - *
> > > >>>>
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecurator-1033/
> > > >>>>> <
> > > >>>>
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecurator-1033/
> > > >>>>> *
> > > >>>>> 3.2.0 - https://repository.
> > > >>>>> apache.org/content/repositories/orgapachecurator-1034
> > > >>>>>
> > > >>>>> The tags to be voted upon:
> > > >>>>> 2.11.0 - *
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=curator.git;a=tag;h=9ac3980e0e7f455a69f44a3b26154f826d8459b7
> > > >>>>> <
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=curator.git;a=tag;h=9ac3980e0e7f455a69f44a3b26154f826d8459b7
> > > >>>>> *
> > > >>>>> 3.2.0 - *
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=curator.git;a=tag;h=5ac624bb9d188f8db87d8de1ae0c256ba1515ddc
> > > >>>>> <
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=curator.git;a=tag;h=5ac624bb9d188f8db87d8de1ae0c256ba1515ddc
> > > >>>>> *
> > > >>>>>
> > > >>>>> 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)
> > > >>>>
> > > >>
> > > >>
> > >
> > >
> >
>

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