zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zili Chen <wander4...@gmail.com>
Subject Re: Releasing 3.6.0 - ALPHA or not ?
Date Wed, 02 Oct 2019 15:59:28 GMT
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 <phunt@apache.org> 于2019年10月2日周三 下午11:40写道:

> On Wed, Oct 2, 2019 at 2:22 AM Enrico Olivelli <eolivelli@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
> > <nkalmar@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 <andor@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 <hanm@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 <phunt@apache.org>
> > wrote:
> > > > >
> > > > >> Enrico these are good ideas, thoughts below:
> > > > >>
> > > > >> On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar
> > > > <nkalmar@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 <
> > eolivelli@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
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message