> 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 >>>>> 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 >>>>>> >>>>>> >>>> >> >>
