Re: reconfig APIs
> > ZooKeeperAdmin which as previously stated is the right thing to do in >>> long >>> > term. If we decide to maintain backward API compatibility for >>> 3.5.3-beta >>> > release, we could add reconfig API back to ZooKeeper but mark it as >>> > deprecated, then remove the API in next major release (3.6 or 4.x). >>> > >>> > >>> > On Thu, Dec 8, 2016 at 8:27 AM, Patrick Hunt <ph...@apache.org> wrote: >>> > >>> >> I've only seen a few questions about versioning come up on the ZK >>> lists, >>> >> they were quickly responded to with pointers to the process. iirc we >>> based >>> >> our versioning scheme on what Hadoop was/is using. Additionally if we >>> don't >>> >> allow for alpha time it will further slow progress as there will be no >>> >> opportunity to adjust things like APIs once they are committed and >>> >> generally available for people to "kick the tires". >>> >> >>> >> I'll leave it up to the rest of the community to state their >>> opinions, but >>> >> as i have stated imo it would be a mistake to revert this change. >>> Jordan >>> >> has raised a reasonable concern - I consider this a blocker for >>> 3.5.3-alpha >>> >> until it is resolved. >>> >> >>> >> Patrick >>> >> >>> >> On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman < >>> >> jor...@jordanzimmerman.com >>> >>> wrote: >>> >> >>> >>>> I think people understand what alpha means. >>> >>> >>> >>> With respect, the ZooKeeper team has used “alpha” in a novel way >>> that is >>> >>> sowing considerable confusion. I wrote emails about this a while >>> back. >>> >> But, >>> >>> here again, is another case where the non-standard usage of “alpha” >>> will >>> >>> cause confusion. To reiterate: someone who sees "3.5.2-alpha” will >>> think >>> >>> that there will eventually be a “3.5.2-beta” and finally a “3.5.2” >>> >> release >>> >>> version. But, with ZooKeeper there will never be a “3.5.2” release. >>> In >>> >>> fact, the “-alpha” label is mis-located. The real version is >>> >>> “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication >>> >> here. >>> >>> If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees >>> >>> “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two >>> >>> different releases. What ZOOKEEPER-2014 has done is remove an >>> existing >>> >> API >>> >>> from what appears to be a released version 3.5.2 (which never really >>> >>> existed). This change violates semantic versioning. For external >>> users, >>> >> the >>> >>> version after “3.5.2” should be “4.x.x” as it has breaking changes. >>> >>> >>> >>>> It's not about style, there were a number of concerns addressed in >>> that >>> >>>> patch. >>> >>> >>> >>> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can >>> be >>> >>> addressed completely without moving the reconfig() methods to a new >>> >> class. >>> >>> It may be useful to move APIs around for clarity, etc. but these >>> breaking >>> >>> changes should be for a version that signals breaking changes - >>> 4.x.x or >>> >>> something. i.e. moving the reconfig() APIs is orthogonal to the >>> concerns >>> >> of >>> >>> ZOOKEEPER-2014 and should be a separate Jira issue. >>> >>> >>> >>>> I think people understand what alpha means. There may be some short >>> >> term >>> >>>> impact for a few, but a significant benefit over the long term. >>> >>> >>> >>> Again with respect - 3.5.0-alpha was made available in Maven Central >>> >>> August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s >>> >> intent, >>> >>> this is NOT an alpha in users’ minds. This is a released library >>> that is >>> >> in >>> >>> production in major organizati
Re: reconfig APIs
ly if we >> don't >> >> allow for alpha time it will further slow progress as there will be no >> >> opportunity to adjust things like APIs once they are committed and >> >> generally available for people to "kick the tires". >> >> >> >> I'll leave it up to the rest of the community to state their opinions, >> but >> >> as i have stated imo it would be a mistake to revert this change. >> Jordan >> >> has raised a reasonable concern - I consider this a blocker for >> 3.5.3-alpha >> >> until it is resolved. >> >> >> >> Patrick >> >> >> >> On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman < >> >> jor...@jordanzimmerman.com >> >>> wrote: >> >> >> >>>> I think people understand what alpha means. >> >>> >> >>> With respect, the ZooKeeper team has used “alpha” in a novel way that >> is >> >>> sowing considerable confusion. I wrote emails about this a while back. >> >> But, >> >>> here again, is another case where the non-standard usage of “alpha” >> will >> >>> cause confusion. To reiterate: someone who sees "3.5.2-alpha” will >> think >> >>> that there will eventually be a “3.5.2-beta” and finally a “3.5.2” >> >> release >> >>> version. But, with ZooKeeper there will never be a “3.5.2” release. In >> >>> fact, the “-alpha” label is mis-located. The real version is >> >>> “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication >> >> here. >> >>> If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees >> >>> “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two >> >>> different releases. What ZOOKEEPER-2014 has done is remove an existing >> >> API >> >>> from what appears to be a released version 3.5.2 (which never really >> >>> existed). This change violates semantic versioning. For external >> users, >> >> the >> >>> version after “3.5.2” should be “4.x.x” as it has breaking changes. >> >>> >> >>>> It's not about style, there were a number of concerns addressed in >> that >> >>>> patch. >> >>> >> >>> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can >> be >> >>> addressed completely without moving the reconfig() methods to a new >> >> class. >> >>> It may be useful to move APIs around for clarity, etc. but these >> breaking >> >>> changes should be for a version that signals breaking changes - 4.x.x >> or >> >>> something. i.e. moving the reconfig() APIs is orthogonal to the >> concerns >> >> of >> >>> ZOOKEEPER-2014 and should be a separate Jira issue. >> >>> >> >>>> I think people understand what alpha means. There may be some short >> >> term >> >>>> impact for a few, but a significant benefit over the long term. >> >>> >> >>> Again with respect - 3.5.0-alpha was made available in Maven Central >> >>> August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s >> >> intent, >> >>> this is NOT an alpha in users’ minds. This is a released library that >> is >> >> in >> >>> production in major organizations. The ZooKeeper team should realize >> this >> >>> and adjust their thinking about the “alpha” tag. For Apache Curator, >> >> we’re >> >>> now put in a position where the reconfig() APIs have disappeared. In >> >> order >> >>> to maintain our own internal semantic versioning we will have to >> >> consider a >> >>> third branch of Curator (we currently have a ZooKeeper 3.4.x >> compatible >> >>> version and a ZooKeeper 3.5.x compatible version). It would be >> awesome if >> >>> we didn’t have to do this. >> >>> >> >>> -Jordan >> >>> >> >>>> On Dec 7, 2016, at 7:16 PM, Patrick Hunt <ph...@apache.org> wrote: >> >>>> >> >>>> It's not about style, there were a number of concerns addressed in >> that >> >>>> patch. We didn't take the change lightly, we've been discussing it >> over >> >>>> jira and the mailing list over the past two years. >> >>>
Re: reconfig APIs
t;> sowing considerable confusion. I wrote emails about this a while back. > >> But, > >>> here again, is another case where the non-standard usage of “alpha” > will > >>> cause confusion. To reiterate: someone who sees "3.5.2-alpha” will > think > >>> that there will eventually be a “3.5.2-beta” and finally a “3.5.2” > >> release > >>> version. But, with ZooKeeper there will never be a “3.5.2” release. In > >>> fact, the “-alpha” label is mis-located. The real version is > >>> “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication > >> here. > >>> If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees > >>> “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two > >>> different releases. What ZOOKEEPER-2014 has done is remove an existing > >> API > >>> from what appears to be a released version 3.5.2 (which never really > >>> existed). This change violates semantic versioning. For external users, > >> the > >>> version after “3.5.2” should be “4.x.x” as it has breaking changes. > >>> > >>>> It's not about style, there were a number of concerns addressed in > that > >>>> patch. > >>> > >>> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be > >>> addressed completely without moving the reconfig() methods to a new > >> class. > >>> It may be useful to move APIs around for clarity, etc. but these > breaking > >>> changes should be for a version that signals breaking changes - 4.x.x > or > >>> something. i.e. moving the reconfig() APIs is orthogonal to the > concerns > >> of > >>> ZOOKEEPER-2014 and should be a separate Jira issue. > >>> > >>>> I think people understand what alpha means. There may be some short > >> term > >>>> impact for a few, but a significant benefit over the long term. > >>> > >>> Again with respect - 3.5.0-alpha was made available in Maven Central > >>> August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s > >> intent, > >>> this is NOT an alpha in users’ minds. This is a released library that > is > >> in > >>> production in major organizations. The ZooKeeper team should realize > this > >>> and adjust their thinking about the “alpha” tag. For Apache Curator, > >> we’re > >>> now put in a position where the reconfig() APIs have disappeared. In > >> order > >>> to maintain our own internal semantic versioning we will have to > >> consider a > >>> third branch of Curator (we currently have a ZooKeeper 3.4.x compatible > >>> version and a ZooKeeper 3.5.x compatible version). It would be awesome > if > >>> we didn’t have to do this. > >>> > >>> -Jordan > >>> > >>>> On Dec 7, 2016, at 7:16 PM, Patrick Hunt <ph...@apache.org> wrote: > >>>> > >>>> It's not about style, there were a number of concerns addressed in > that > >>>> patch. We didn't take the change lightly, we've been discussing it > over > >>>> jira and the mailing list over the past two years. > >>>> > >>>> I think people understand what alpha means. There may be some short > >> term > >>>> impact for a few, but a significant benefit over the long term. > >>>> > >>>> Patrick > >>>> > >>>> On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" < > jor...@jordanzimmerman.com > >>> > >>>> wrote: > >>>> > >>>>> I read through the issue and disagree about the decision to move the > >>> APIs > >>>>> out. That was a stylistic choice that breaks client code. I realize > >> that > >>>>> 3.5.x has been advertised as an alpha but you must realize that most > >> of > >>> the > >>>>> world is using it in production. These APIs have now been published. > >>> This > >>>>> will create a real headache for Curator which is why I’ve created > >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 < > >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we > can > >>>>> move these APIs back into ZooKeeper.java. > >>>>> > >>>>> -Jordan > >>>>>
Re: reconfig APIs
; >>> that there will eventually be a “3.5.2-beta” and finally a “3.5.2” > >> release > >>> version. But, with ZooKeeper there will never be a “3.5.2” release. In > >>> fact, the “-alpha” label is mis-located. The real version is > >>> “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication > >> here. > >>> If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees > >>> “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two > >>> different releases. What ZOOKEEPER-2014 has done is remove an existing > >> API > >>> from what appears to be a released version 3.5.2 (which never really > >>> existed). This change violates semantic versioning. For external users, > >> the > >>> version after “3.5.2” should be “4.x.x” as it has breaking changes. > >>> > >>>> It's not about style, there were a number of concerns addressed in > that > >>>> patch. > >>> > >>> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be > >>> addressed completely without moving the reconfig() methods to a new > >> class. > >>> It may be useful to move APIs around for clarity, etc. but these > breaking > >>> changes should be for a version that signals breaking changes - 4.x.x > or > >>> something. i.e. moving the reconfig() APIs is orthogonal to the > concerns > >> of > >>> ZOOKEEPER-2014 and should be a separate Jira issue. > >>> > >>>> I think people understand what alpha means. There may be some short > >> term > >>>> impact for a few, but a significant benefit over the long term. > >>> > >>> Again with respect - 3.5.0-alpha was made available in Maven Central > >>> August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s > >> intent, > >>> this is NOT an alpha in users’ minds. This is a released library that > is > >> in > >>> production in major organizations. The ZooKeeper team should realize > this > >>> and adjust their thinking about the “alpha” tag. For Apache Curator, > >> we’re > >>> now put in a position where the reconfig() APIs have disappeared. In > >> order > >>> to maintain our own internal semantic versioning we will have to > >> consider a > >>> third branch of Curator (we currently have a ZooKeeper 3.4.x compatible > >>> version and a ZooKeeper 3.5.x compatible version). It would be awesome > if > >>> we didn’t have to do this. > >>> > >>> -Jordan > >>> > >>>> On Dec 7, 2016, at 7:16 PM, Patrick Hunt <ph...@apache.org> wrote: > >>>> > >>>> It's not about style, there were a number of concerns addressed in > that > >>>> patch. We didn't take the change lightly, we've been discussing it > over > >>>> jira and the mailing list over the past two years. > >>>> > >>>> I think people understand what alpha means. There may be some short > >> term > >>>> impact for a few, but a significant benefit over the long term. > >>>> > >>>> Patrick > >>>> > >>>> On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" < > jor...@jordanzimmerman.com > >>> > >>>> wrote: > >>>> > >>>>> I read through the issue and disagree about the decision to move the > >>> APIs > >>>>> out. That was a stylistic choice that breaks client code. I realize > >> that > >>>>> 3.5.x has been advertised as an alpha but you must realize that most > >> of > >>> the > >>>>> world is using it in production. These APIs have now been published. > >>> This > >>>>> will create a real headache for Curator which is why I’ve created > >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 < > >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we > can > >>>>> move these APIs back into ZooKeeper.java. > >>>>> > >>>>> -Jordan > >>>>> > >>>>>> On Dec 7, 2016, at 5:54 PM, Patrick Hunt <ph...@apache.org> wrote: > >>>>>> > >>>>>> It's discussed in more depth in the JIRA iirc, but basically; > >>>>>> ZooKeeper.java provides client
Re: reconfig APIs
version 3.5.2 (which never really >>> existed). This change violates semantic versioning. For external users, >> the >>> version after “3.5.2” should be “4.x.x” as it has breaking changes. >>> >>>> It's not about style, there were a number of concerns addressed in that >>>> patch. >>> >>> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be >>> addressed completely without moving the reconfig() methods to a new >> class. >>> It may be useful to move APIs around for clarity, etc. but these breaking >>> changes should be for a version that signals breaking changes - 4.x.x or >>> something. i.e. moving the reconfig() APIs is orthogonal to the concerns >> of >>> ZOOKEEPER-2014 and should be a separate Jira issue. >>> >>>> I think people understand what alpha means. There may be some short >> term >>>> impact for a few, but a significant benefit over the long term. >>> >>> Again with respect - 3.5.0-alpha was made available in Maven Central >>> August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s >> intent, >>> this is NOT an alpha in users’ minds. This is a released library that is >> in >>> production in major organizations. The ZooKeeper team should realize this >>> and adjust their thinking about the “alpha” tag. For Apache Curator, >> we’re >>> now put in a position where the reconfig() APIs have disappeared. In >> order >>> to maintain our own internal semantic versioning we will have to >> consider a >>> third branch of Curator (we currently have a ZooKeeper 3.4.x compatible >>> version and a ZooKeeper 3.5.x compatible version). It would be awesome if >>> we didn’t have to do this. >>> >>> -Jordan >>> >>>> On Dec 7, 2016, at 7:16 PM, Patrick Hunt <ph...@apache.org> wrote: >>>> >>>> It's not about style, there were a number of concerns addressed in that >>>> patch. We didn't take the change lightly, we've been discussing it over >>>> jira and the mailing list over the past two years. >>>> >>>> I think people understand what alpha means. There may be some short >> term >>>> impact for a few, but a significant benefit over the long term. >>>> >>>> Patrick >>>> >>>> On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com >>> >>>> wrote: >>>> >>>>> I read through the issue and disagree about the decision to move the >>> APIs >>>>> out. That was a stylistic choice that breaks client code. I realize >> that >>>>> 3.5.x has been advertised as an alpha but you must realize that most >> of >>> the >>>>> world is using it in production. These APIs have now been published. >>> This >>>>> will create a real headache for Curator which is why I’ve created >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 < >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can >>>>> move these APIs back into ZooKeeper.java. >>>>> >>>>> -Jordan >>>>> >>>>>> On Dec 7, 2016, at 5:54 PM, Patrick Hunt <ph...@apache.org> wrote: >>>>>> >>>>>> It's discussed in more depth in the JIRA iirc, but basically; >>>>>> ZooKeeper.java provides client APIs, reconfig is an admiistrative >> API. >>>>>> >>>>>> Patrick >>>>>> >>>>>> On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman < >>>>> jor...@jordanzimmerman.com >>>>>>> wrote: >>>>>> >>>>>>> I understand the need to make the methods require proper auth but >>>>> there's >>>>>>> no reason to move it to a different class that I can see. Am I >> missing >>>>>>> something? >>>>>>> >>>>>>> >>>>>>> Jordan Zimmerman >>>>>>> >>>>>>>> On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: >>>>>>>> >>>>>>>> This problem has been a long standing blocker issue for 3.5 and >>>>>>> identified >>>>>>>> early on as something that would need to change. This has been one >> of >>>>> the >>>>>>>> reasons why 3.5 has stayed in alpha - because we allow non-backward >>>>>>>> compatible changes to new APIs in alpha and we knew we would have >> to >>>>> fix >>>>>>>> this. The description/comments of ZOOKEEPER-2014 does a good job >>>>>>>> documenting why this had to change. >>>>>>>> >>>>>>>> Patrick >>>>>>>> >>>>>>>> On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman < >>>>>>> jor...@jordanzimmerman.com >>>>>>>>> wrote: >>>>>>>> >>>>>>>>> OK - I found the offending issue: ZOOKEEPER-2014 >>>>>>>>> >>>>>>>>> What is the benefit/logic of moving the reconfig() variants into a >>> new >>>>>>>>> class? I can see if this was done from the start but you have now >>>>> broken >>>>>>>>> Curator in a fairly serious non-backward compatible way for a >> minor >>>>>>>>> documenting benefit. Does anyone object to me reversing this? >>>>>>>>> >>>>>>>>> -Jordan >>>>>>>>> >>>>>>>>>> On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < >>>>>>>>> jor...@jordanzimmerman.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I was compiling Curator against the ZK master and noticed that >> the >>>>>>>>> reconfig APIs are gone/changed. Can anyone point me at the issues >>> for >>>>>>> this >>>>>>>>> and/or the discussion why this breaking change was made? >>>>>>>>>> >>>>>>>>>> -Jordan >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> > > > > -- > Cheers > Michael.
Re: reconfig APIs
Thanks Jordan for raising the concern. It's a reasonable concern with good intention to make user's life easier, which is important to the project. There are two separate issues we need to reach a consensus here: * Move reconfig API The details of why the decision was made is documented in ZOOKEEPER-2014 JIRA, but just to recap, the API is moved because it's the right thing to do in long term, which yield a cleaner interface design for ZooKeeper client API. In future, we might also want to clean up other APIs (i.e. move quota related APIs over as well.) as well. While seemingly stylish as it might look like, I believe a clean API is also important for a project's usability / adoption. From the discussions so far I think everyone either agree with this, or have no strong opinion against it, so I consider this question is solved. * Backward compatibility between releases Since we decide refactor reconfig API, the question is when. The reconfig API was removed from ZOOKEEPER-2014 (which targets 3.5.3 alpha) because of the definition of alpha / beta releases in the context of ZooKeeper project (I'm not saying this is right or wrong, simply state a fact up to date): an alpha release implies that we allow backward incompatible changes, and a beta release implies that the APIs are locked down and none backward compatible change. Given this definition, it is perfectly legitimate to move API around w/o considering compatibility. Now what Jordan pointed out regarding definition of 'alpha' combined with some old discussion threads I found in user list indicate that our definition of 'alpha', and 'beta' is none standard and could cause confusions. So I think we should try reach a consensus on whether we stick with current definition of 'alpha' and 'beta' release during 3.5.3 release cycle, or adopt something else. With all these said, I think options are: * Do nothing, stick with current alpha / beta definition. * Try redefine what 'alpha' and 'beta' means in the context of ZooKeeper and then go from there in 3.5.3 release cycle. In any cases, I'd like to propose we keep the reconfig API in ZooKeeperAdmin which as previously stated is the right thing to do in long term. If we decide to maintain backward API compatibility for 3.5.3-beta release, we could add reconfig API back to ZooKeeper but mark it as deprecated, then remove the API in next major release (3.6 or 4.x). On Thu, Dec 8, 2016 at 8:27 AM, Patrick Hunt <ph...@apache.org> wrote: > I've only seen a few questions about versioning come up on the ZK lists, > they were quickly responded to with pointers to the process. iirc we based > our versioning scheme on what Hadoop was/is using. Additionally if we don't > allow for alpha time it will further slow progress as there will be no > opportunity to adjust things like APIs once they are committed and > generally available for people to "kick the tires". > > I'll leave it up to the rest of the community to state their opinions, but > as i have stated imo it would be a mistake to revert this change. Jordan > has raised a reasonable concern - I consider this a blocker for 3.5.3-alpha > until it is resolved. > > Patrick > > On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman < > jor...@jordanzimmerman.com > > wrote: > > > > I think people understand what alpha means. > > > > With respect, the ZooKeeper team has used “alpha” in a novel way that is > > sowing considerable confusion. I wrote emails about this a while back. > But, > > here again, is another case where the non-standard usage of “alpha” will > > cause confusion. To reiterate: someone who sees "3.5.2-alpha” will think > > that there will eventually be a “3.5.2-beta” and finally a “3.5.2” > release > > version. But, with ZooKeeper there will never be a “3.5.2” release. In > > fact, the “-alpha” label is mis-located. The real version is > > “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication > here. > > If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees > > “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two > > different releases. What ZOOKEEPER-2014 has done is remove an existing > API > > from what appears to be a released version 3.5.2 (which never really > > existed). This change violates semantic versioning. For external users, > the > > version after “3.5.2” should be “4.x.x” as it has breaking changes. > > > > > It's not about style, there were a number of concerns addressed in that > > > patch. > > > > The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be > > addressed completely without moving the reconfig() methods to a new > class. > > It may be useful to move APIs around for clarity, etc. but these breaking > > changes sho
Re: reconfig APIs
I've only seen a few questions about versioning come up on the ZK lists, they were quickly responded to with pointers to the process. iirc we based our versioning scheme on what Hadoop was/is using. Additionally if we don't allow for alpha time it will further slow progress as there will be no opportunity to adjust things like APIs once they are committed and generally available for people to "kick the tires". I'll leave it up to the rest of the community to state their opinions, but as i have stated imo it would be a mistake to revert this change. Jordan has raised a reasonable concern - I consider this a blocker for 3.5.3-alpha until it is resolved. Patrick On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > > I think people understand what alpha means. > > With respect, the ZooKeeper team has used “alpha” in a novel way that is > sowing considerable confusion. I wrote emails about this a while back. But, > here again, is another case where the non-standard usage of “alpha” will > cause confusion. To reiterate: someone who sees "3.5.2-alpha” will think > that there will eventually be a “3.5.2-beta” and finally a “3.5.2” release > version. But, with ZooKeeper there will never be a “3.5.2” release. In > fact, the “-alpha” label is mis-located. The real version is > “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication here. > If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees > “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two > different releases. What ZOOKEEPER-2014 has done is remove an existing API > from what appears to be a released version 3.5.2 (which never really > existed). This change violates semantic versioning. For external users, the > version after “3.5.2” should be “4.x.x” as it has breaking changes. > > > It's not about style, there were a number of concerns addressed in that > > patch. > > The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be > addressed completely without moving the reconfig() methods to a new class. > It may be useful to move APIs around for clarity, etc. but these breaking > changes should be for a version that signals breaking changes - 4.x.x or > something. i.e. moving the reconfig() APIs is orthogonal to the concerns of > ZOOKEEPER-2014 and should be a separate Jira issue. > > > I think people understand what alpha means. There may be some short term > > impact for a few, but a significant benefit over the long term. > > Again with respect - 3.5.0-alpha was made available in Maven Central > August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s intent, > this is NOT an alpha in users’ minds. This is a released library that is in > production in major organizations. The ZooKeeper team should realize this > and adjust their thinking about the “alpha” tag. For Apache Curator, we’re > now put in a position where the reconfig() APIs have disappeared. In order > to maintain our own internal semantic versioning we will have to consider a > third branch of Curator (we currently have a ZooKeeper 3.4.x compatible > version and a ZooKeeper 3.5.x compatible version). It would be awesome if > we didn’t have to do this. > > -Jordan > > > On Dec 7, 2016, at 7:16 PM, Patrick Hunt <ph...@apache.org> wrote: > > > > It's not about style, there were a number of concerns addressed in that > > patch. We didn't take the change lightly, we've been discussing it over > > jira and the mailing list over the past two years. > > > > I think people understand what alpha means. There may be some short term > > impact for a few, but a significant benefit over the long term. > > > > Patrick > > > > On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com> > > wrote: > > > >> I read through the issue and disagree about the decision to move the > APIs > >> out. That was a stylistic choice that breaks client code. I realize that > >> 3.5.x has been advertised as an alpha but you must realize that most of > the > >> world is using it in production. These APIs have now been published. > This > >> will create a real headache for Curator which is why I’ve created > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 < > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can > >> move these APIs back into ZooKeeper.java. > >> > >> -Jordan > >> > >>> On Dec 7, 2016, at 5:54 PM, Patrick Hunt <ph...@apache.org> wrote: > >>> > >>> It's discussed in more depth in the JIRA iirc, but basically; > >>> ZooKeep
Re: reconfig APIs
> I think people understand what alpha means. With respect, the ZooKeeper team has used “alpha” in a novel way that is sowing considerable confusion. I wrote emails about this a while back. But, here again, is another case where the non-standard usage of “alpha” will cause confusion. To reiterate: someone who sees "3.5.2-alpha” will think that there will eventually be a “3.5.2-beta” and finally a “3.5.2” release version. But, with ZooKeeper there will never be a “3.5.2” release. In fact, the “-alpha” label is mis-located. The real version is “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication here. If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two different releases. What ZOOKEEPER-2014 has done is remove an existing API from what appears to be a released version 3.5.2 (which never really existed). This change violates semantic versioning. For external users, the version after “3.5.2” should be “4.x.x” as it has breaking changes. > It's not about style, there were a number of concerns addressed in that > patch. The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be addressed completely without moving the reconfig() methods to a new class. It may be useful to move APIs around for clarity, etc. but these breaking changes should be for a version that signals breaking changes - 4.x.x or something. i.e. moving the reconfig() APIs is orthogonal to the concerns of ZOOKEEPER-2014 and should be a separate Jira issue. > I think people understand what alpha means. There may be some short term > impact for a few, but a significant benefit over the long term. Again with respect - 3.5.0-alpha was made available in Maven Central August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s intent, this is NOT an alpha in users’ minds. This is a released library that is in production in major organizations. The ZooKeeper team should realize this and adjust their thinking about the “alpha” tag. For Apache Curator, we’re now put in a position where the reconfig() APIs have disappeared. In order to maintain our own internal semantic versioning we will have to consider a third branch of Curator (we currently have a ZooKeeper 3.4.x compatible version and a ZooKeeper 3.5.x compatible version). It would be awesome if we didn’t have to do this. -Jordan > On Dec 7, 2016, at 7:16 PM, Patrick Hunt <ph...@apache.org> wrote: > > It's not about style, there were a number of concerns addressed in that > patch. We didn't take the change lightly, we've been discussing it over > jira and the mailing list over the past two years. > > I think people understand what alpha means. There may be some short term > impact for a few, but a significant benefit over the long term. > > Patrick > > On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com> > wrote: > >> I read through the issue and disagree about the decision to move the APIs >> out. That was a stylistic choice that breaks client code. I realize that >> 3.5.x has been advertised as an alpha but you must realize that most of the >> world is using it in production. These APIs have now been published. This >> will create a real headache for Curator which is why I’ve created >> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 < >> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can >> move these APIs back into ZooKeeper.java. >> >> -Jordan >> >>> On Dec 7, 2016, at 5:54 PM, Patrick Hunt <ph...@apache.org> wrote: >>> >>> It's discussed in more depth in the JIRA iirc, but basically; >>> ZooKeeper.java provides client APIs, reconfig is an admiistrative API. >>> >>> Patrick >>> >>> On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman < >> jor...@jordanzimmerman.com >>>> wrote: >>> >>>> I understand the need to make the methods require proper auth but >> there's >>>> no reason to move it to a different class that I can see. Am I missing >>>> something? >>>> >>>> >>>> Jordan Zimmerman >>>> >>>>> On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: >>>>> >>>>> This problem has been a long standing blocker issue for 3.5 and >>>> identified >>>>> early on as something that would need to change. This has been one of >> the >>>>> reasons why 3.5 has stayed in alpha - because we allow non-backward >>>>> compatible changes to new APIs in alpha and we knew we would have to >> fix >>>>
Re: reconfig APIs
It's not about style, there were a number of concerns addressed in that patch. We didn't take the change lightly, we've been discussing it over jira and the mailing list over the past two years. I think people understand what alpha means. There may be some short term impact for a few, but a significant benefit over the long term. Patrick On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com> wrote: > I read through the issue and disagree about the decision to move the APIs > out. That was a stylistic choice that breaks client code. I realize that > 3.5.x has been advertised as an alpha but you must realize that most of the > world is using it in production. These APIs have now been published. This > will create a real headache for Curator which is why I’ve created > https://issues.apache.org/jira/browse/ZOOKEEPER-2642 < > https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can > move these APIs back into ZooKeeper.java. > > -Jordan > > > On Dec 7, 2016, at 5:54 PM, Patrick Hunt <ph...@apache.org> wrote: > > > > It's discussed in more depth in the JIRA iirc, but basically; > > ZooKeeper.java provides client APIs, reconfig is an admiistrative API. > > > > Patrick > > > > On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman < > jor...@jordanzimmerman.com > >> wrote: > > > >> I understand the need to make the methods require proper auth but > there's > >> no reason to move it to a different class that I can see. Am I missing > >> something? > >> > >> > >> Jordan Zimmerman > >> > >>> On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: > >>> > >>> This problem has been a long standing blocker issue for 3.5 and > >> identified > >>> early on as something that would need to change. This has been one of > the > >>> reasons why 3.5 has stayed in alpha - because we allow non-backward > >>> compatible changes to new APIs in alpha and we knew we would have to > fix > >>> this. The description/comments of ZOOKEEPER-2014 does a good job > >>> documenting why this had to change. > >>> > >>> Patrick > >>> > >>> On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman < > >> jor...@jordanzimmerman.com > >>>> wrote: > >>> > >>>> OK - I found the offending issue: ZOOKEEPER-2014 > >>>> > >>>> What is the benefit/logic of moving the reconfig() variants into a new > >>>> class? I can see if this was done from the start but you have now > broken > >>>> Curator in a fairly serious non-backward compatible way for a minor > >>>> documenting benefit. Does anyone object to me reversing this? > >>>> > >>>> -Jordan > >>>> > >>>>> On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < > >>>> jor...@jordanzimmerman.com> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I was compiling Curator against the ZK master and noticed that the > >>>> reconfig APIs are gone/changed. Can anyone point me at the issues for > >> this > >>>> and/or the discussion why this breaking change was made? > >>>>> > >>>>> -Jordan > >>>> > >>>> > >> > >
Re: reconfig APIs
I read through the issue and disagree about the decision to move the APIs out. That was a stylistic choice that breaks client code. I realize that 3.5.x has been advertised as an alpha but you must realize that most of the world is using it in production. These APIs have now been published. This will create a real headache for Curator which is why I’ve created https://issues.apache.org/jira/browse/ZOOKEEPER-2642 <https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can move these APIs back into ZooKeeper.java. -Jordan > On Dec 7, 2016, at 5:54 PM, Patrick Hunt <ph...@apache.org> wrote: > > It's discussed in more depth in the JIRA iirc, but basically; > ZooKeeper.java provides client APIs, reconfig is an admiistrative API. > > Patrick > > On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman <jor...@jordanzimmerman.com >> wrote: > >> I understand the need to make the methods require proper auth but there's >> no reason to move it to a different class that I can see. Am I missing >> something? >> >> >> Jordan Zimmerman >> >>> On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: >>> >>> This problem has been a long standing blocker issue for 3.5 and >> identified >>> early on as something that would need to change. This has been one of the >>> reasons why 3.5 has stayed in alpha - because we allow non-backward >>> compatible changes to new APIs in alpha and we knew we would have to fix >>> this. The description/comments of ZOOKEEPER-2014 does a good job >>> documenting why this had to change. >>> >>> Patrick >>> >>> On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman < >> jor...@jordanzimmerman.com >>>> wrote: >>> >>>> OK - I found the offending issue: ZOOKEEPER-2014 >>>> >>>> What is the benefit/logic of moving the reconfig() variants into a new >>>> class? I can see if this was done from the start but you have now broken >>>> Curator in a fairly serious non-backward compatible way for a minor >>>> documenting benefit. Does anyone object to me reversing this? >>>> >>>> -Jordan >>>> >>>>> On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < >>>> jor...@jordanzimmerman.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I was compiling Curator against the ZK master and noticed that the >>>> reconfig APIs are gone/changed. Can anyone point me at the issues for >> this >>>> and/or the discussion why this breaking change was made? >>>>> >>>>> -Jordan >>>> >>>> >>
Re: reconfig APIs
It's discussed in more depth in the JIRA iirc, but basically; ZooKeeper.java provides client APIs, reconfig is an admiistrative API. Patrick On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > I understand the need to make the methods require proper auth but there's > no reason to move it to a different class that I can see. Am I missing > something? > > > Jordan Zimmerman > > > On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: > > > > This problem has been a long standing blocker issue for 3.5 and > identified > > early on as something that would need to change. This has been one of the > > reasons why 3.5 has stayed in alpha - because we allow non-backward > > compatible changes to new APIs in alpha and we knew we would have to fix > > this. The description/comments of ZOOKEEPER-2014 does a good job > > documenting why this had to change. > > > > Patrick > > > > On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman < > jor...@jordanzimmerman.com > >> wrote: > > > >> OK - I found the offending issue: ZOOKEEPER-2014 > >> > >> What is the benefit/logic of moving the reconfig() variants into a new > >> class? I can see if this was done from the start but you have now broken > >> Curator in a fairly serious non-backward compatible way for a minor > >> documenting benefit. Does anyone object to me reversing this? > >> > >> -Jordan > >> > >>> On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < > >> jor...@jordanzimmerman.com> wrote: > >>> > >>> Hi, > >>> > >>> I was compiling Curator against the ZK master and noticed that the > >> reconfig APIs are gone/changed. Can anyone point me at the issues for > this > >> and/or the discussion why this breaking change was made? > >>> > >>> -Jordan > >> > >> >
Re: reconfig APIs
I understand the need to make the methods require proper auth but there's no reason to move it to a different class that I can see. Am I missing something? Jordan Zimmerman > On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: > > This problem has been a long standing blocker issue for 3.5 and identified > early on as something that would need to change. This has been one of the > reasons why 3.5 has stayed in alpha - because we allow non-backward > compatible changes to new APIs in alpha and we knew we would have to fix > this. The description/comments of ZOOKEEPER-2014 does a good job > documenting why this had to change. > > Patrick > > On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman <jor...@jordanzimmerman.com >> wrote: > >> OK - I found the offending issue: ZOOKEEPER-2014 >> >> What is the benefit/logic of moving the reconfig() variants into a new >> class? I can see if this was done from the start but you have now broken >> Curator in a fairly serious non-backward compatible way for a minor >> documenting benefit. Does anyone object to me reversing this? >> >> -Jordan >> >>> On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < >> jor...@jordanzimmerman.com> wrote: >>> >>> Hi, >>> >>> I was compiling Curator against the ZK master and noticed that the >> reconfig APIs are gone/changed. Can anyone point me at the issues for this >> and/or the discussion why this breaking change was made? >>> >>> -Jordan >> >>
Re: reconfig APIs
This problem has been a long standing blocker issue for 3.5 and identified early on as something that would need to change. This has been one of the reasons why 3.5 has stayed in alpha - because we allow non-backward compatible changes to new APIs in alpha and we knew we would have to fix this. The description/comments of ZOOKEEPER-2014 does a good job documenting why this had to change. Patrick On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > OK - I found the offending issue: ZOOKEEPER-2014 > > What is the benefit/logic of moving the reconfig() variants into a new > class? I can see if this was done from the start but you have now broken > Curator in a fairly serious non-backward compatible way for a minor > documenting benefit. Does anyone object to me reversing this? > > -Jordan > > > On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < > jor...@jordanzimmerman.com> wrote: > > > > Hi, > > > > I was compiling Curator against the ZK master and noticed that the > reconfig APIs are gone/changed. Can anyone point me at the issues for this > and/or the discussion why this breaking change was made? > > > > -Jordan > >
Re: reconfig APIs
OK - I found the offending issue: ZOOKEEPER-2014 What is the benefit/logic of moving the reconfig() variants into a new class? I can see if this was done from the start but you have now broken Curator in a fairly serious non-backward compatible way for a minor documenting benefit. Does anyone object to me reversing this? -Jordan > On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman <jor...@jordanzimmerman.com> > wrote: > > Hi, > > I was compiling Curator against the ZK master and noticed that the reconfig > APIs are gone/changed. Can anyone point me at the issues for this and/or the > discussion why this breaking change was made? > > -Jordan
reconfig APIs
Hi, I was compiling Curator against the ZK master and noticed that the reconfig APIs are gone/changed. Can anyone point me at the issues for this and/or the discussion why this breaking change was made? -Jordan
