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