Might be worth coming up with a proposal (ie review all the existing 4.x jira and other wish list and put a "proposal" wiki page together for 4.0?)
An option is start with a couple of proposals pages under our wiki page[1] whether or not we process the major bump it helps memorize ideas and consensus of our community discussions and can be fast referred to. Best, tison. [1] https://cwiki.apache.org/confluence/display/HADOOP2/ZooKeeper Patrick Hunt <ph...@apache.org> 于2019年10月2日周三 下午11:40写道： > On Wed, Oct 2, 2019 at 2:22 AM Enrico Olivelli <eolive...@gmail.com> > 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 > ? > > > > > Major version change means "not backward compatible". We've been at Apache > for > 10 years and never had to do this. Is it justified? ie what changes > would we make. I can think of a few; update the API to address some long > standing painpoints - ie version numbers are 32 bit ->64, fix the "epoch > overlaps zxid" which is a major PITA IMO, no checksum in the messages, > replace jute with protobuf, etc... > > That's going to break alot of downstreams. As such it would make sense to > have 3.7... while 4.0 was in play? Or keep b/w compat and address the > things I mentioned above (doable but more costly and time consuming, less > clean, etc...) > > Depends what we want to accomplish. Given the uptick in community activity > it might be a great time to try. Might be worth coming up with a proposal > (ie review all the existing 4.x jira and other wish list and put a > "proposal" wiki page together for 4.0?) > > > > 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. > > > > > Yes. Make it short whatever you do. But providing an "onramp" sounds like a > reasonable approach to me. > > Regards, > > Patrick > > > > 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 > > <nkal...@cloudera.com.invalid> 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 <an...@apache.org> 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 <h...@apache.org> 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 <ph...@apache.org> > > wrote: > > > > > > > > > >> Enrico these are good ideas, thoughts below: > > > > >> > > > > >> On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar > > > > <nkal...@cloudera.com.invalid > > > > >>> > > > > >> 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 < > > eolive...@gmail.com> > > > > >>> 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 > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
