I think we should put the naming up for a vote. Enrico’s description about BookKeeper concept is quite convincing. I’m happy to go without any suffix too.
I also believe that once we cut the new branch (branch-3.6), we should strictly close it from new feature patches. Master should be bumped to 4.0.0 (we talked about it previously - maybe at a meetup?) and new features should go into that. That’s essentially why I’m asking on the other thread for features which could possibly be submitted before the release. Andor > On 2019. Oct 2., at 11:21, Enrico Olivelli <[email protected]> wrote: > > If we release a 3.6.0-beta, shall the master point to 3.6.x ? or will we > bump the version to 4.0.0 or 3.7.0 ? > are we creating a branch-3.6, will it be open for new features/refactors ? > > Ideally once we cut a major release we move all the development and all of > the new features to master branch = next major release. > > In BookKeeper we have a concept of "latest stable" and "last released": > - master branch -> not ready for production, not released yet > - last released (3.6.0 in our case) -> latest and greatest, no blocker > issues, it can be used in production, maybe not yet widespread, no more API > changes, allow minor improvements backported from master branch > - latest stable (3.5.6) in out case-> last point release of latest release > branch, the branch has been around for some time and it is proven to be > stable in production, only critical fixes accepted > > So I am leaning toward a 3.6.0 release, it is simpler for users (every > role) to understand. > People know that as soon as a major release is cut some issue may be > encountered, this is why many companies wait to move to next major version > only after one or two point releases are available. > > btw I can live with a 3.6.0-beta, but with some constraint on a release > within a couple of months, ZooKeeper community is more and more active, it > is becoming simpler to commit patches and cut releases. > > I will also be happy to drive this release as RM, whatever path we decide > as a community > > Enrico > > > > > > > Il giorno mer 2 ott 2019 alle ore 11:04 Norbert Kalmar > <[email protected]> ha scritto: > >> So if I understand this, "3.6.0-beta" (let's cut the 1 here as maybe no >> need for a second beta?) and after a fixed time (say about 3 month) >> "3.6.0-beta2" OR "3.6.0" if it seems fit (vote on it again). >> This sounds good to me, +1 (non-binding). >> >> Regards, >> Norbert >> >> On Wed, Oct 2, 2019 at 10:54 AM Andor Molnar <[email protected]> wrote: >> >>> Hi, >>> >>> I second Pat’s suggestion about release in beta for a fixed period and >>> after that follow Norbert’s versioning scheme: 3.6.0-beta1, 3.6.0-beta2, >> … >>> , 3.6.0 >>> >>> Regards, >>> Andor >>> >>> >>> >>> >>>> On 2019. Oct 2., at 2:23, Michael Han <[email protected]> wrote: >>>> >>>> I am leaning towards release master as 3.6.0 as well, not with any >>> suffix. >>>> We don't have any pending unstable API for 3.6 (like dynamic >>>> reconfiguration to 3.5) that justify the added overheads of using a non >>>> standard, ZooKeeper specific versioning scheme for master branch. >>>> >>>> See >>>> >>> >> http://zookeeper-user.578899.n2.nabble.com/Question-about-3-5-0-stability-and-versioning-td7580927.html >>>> for >>>> some context on why the decision was made and the complains. >>>> >>>> >>>> On Tue, Oct 1, 2019 at 7:11 AM Patrick Hunt <[email protected]> wrote: >>>> >>>>> Enrico these are good ideas, thoughts below: >>>>> >>>>> On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar >>> <[email protected] >>>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> 3.5 had a lot of new features that wasn't really finalized, so API >>>>> changed >>>>>> until stable 3.5 (3.5.5). But I don't think this is the case with >>> 3.6.0, >>>>> we >>>>>> have complete and pretty much finalized features as far as I can >> tell. >>>>>> Also, it did confuse me that with the beta and alpha releases on 3.5 >>>>> minor >>>>>> version jumped as well. So if we want to stick with alpha/beta >>> qualifier, >>>>>> let's keep it at 3.6.0-alpha and 3.6.0-beta (not like 3.6.2-beta). >>>>>> >>>>>> >>>>> That is a good point Norbert. We did try to say "alpha/beta is >> unstable" >>>>> (apis/code/etc...). That worked fairly well, but we were in that state >>> for >>>>> so long that people started using it in production and then got upset >>> when >>>>> we did change the APIs (whatever). As such I would say this is only >>>>> partially successful. Perhaps it would have been more successful if we >>> had >>>>> limited the beta time down more, however folks kept increasing the >> scope >>>>> (by committing new features to 3.5 rather than trunk) and that ended >> up >>>>> continually pushing out the dates. >>>>> >>>>> >>>>>> I don't know any change that would justify an "alpha" version, so >>> maybe a >>>>>> beta would be better? But I'm also just fine releasing just "3.6.0". >>>>> Bugfix >>>>>> version is zero, everyone pretty much knows what that means :) >>>>>> >>>>> >>>>> Perhaps a limited "beta" to allow folks to bang on it, then a planned >>> move >>>>> to "stable"? You could say we'll release it as beta for 3 months then >>> move >>>>> to stable if there are no major issues. The problem with just >> releasing >>>>> straight to stable is that many folks won't try it out from source and >>>>> would only try a binary. >>>>> >>>>> Patrick >>>>> >>>>> >>>>>> >>>>>> So I lean toward leaving alpha and beta out of the version. >>>>>> >>>>>> Regards, >>>>>> Norbert >>>>>> >>>>>> On Tue, Oct 1, 2019 at 2:34 PM Enrico Olivelli <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> We are close to a release for 3.6.0, currently master branch is full >>> of >>>>>>> important features and important refactors. >>>>>>> >>>>>>> On the VOTE thread for 3.5.6 it came out that we could release 3.6.0 >>> as >>>>>>> "ALPHA", here are my thoughts. >>>>>>> >>>>>>> I think we have at least these kind of "users": >>>>>>> - Companies that run the Server on the most recent "stable" release >>>>>>> - Companies that running a ZooKeeper cluster just because another >>>>> system >>>>>>> depends on it (HBase, Kafka,Solr, Pulsar....) >>>>>>> - Library maintainers (Kafka, BookKeeper, HBase), they depend on a >>>>>> version >>>>>>> of the client or on some feature of the server >>>>>>> - Application developers >>>>>>> - Big companies that maintain their own forks and/or are using the >>>>>> "master" >>>>>>> version >>>>>>> >>>>>>> With my library maintainer hat I feel I cannot depend on some >> "ALPHA" >>>>>>> version of ZooKeeper client and make my users setup an ALPHA >> version >>>>> of >>>>>>> the server. >>>>>>> It happened on BookKeeper for instance, we started to depend on ZK >> 3.5 >>>>>> but >>>>>>> as it was BETA so we needed to revert back to 3.4. >>>>>>> I think that some similar story happened in Kafka, now that we have >>> 3.5 >>>>>>> with SSL support users are going to migrate. >>>>>>> >>>>>>> If there is no blocker issue on 3.6.0 I feel we should dare to >> release >>>>> it >>>>>>> as "stable", we can always suggest users and companies to try out >>>>> current >>>>>>> master and give feedback. >>>>>>> >>>>>>> I am new to this story of tagging as "ALPHA"/"BETA" on ZooKeeper, >> but >>>>> as >>>>>> an >>>>>>> user and library maintainer I suffered a lot that '-ALPHA' and >> '-BETA' >>>>>>> suffixes. >>>>>>> I know that ZooKeeper is the core of most of the other systems and >> we >>>>>>> should not suggest to use something that it is "experimental", but >> as >>>>> far >>>>>>> as I know we are taking great care about being backward compatible >> and >>>>>>> about the quality of our code base. >>>>>>> >>>>>>> Other opinions ? >>>>>>> >>>>>>> Enrico >>>>>>> >>>>>> >>>>> >>> >>> >>
