zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: reconfig APIs
Date Thu, 08 Dec 2016 09:46:42 GMT
> 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 <phunt@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" <jordan@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 <phunt@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 <
>> jordan@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 <phunt@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 <
>>>> jordan@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 <
>>>>>> jordan@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
>>>>>> 
>>>>>> 
>>>> 
>> 
>> 


Mime
View raw message