zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Releasing 3.6.0 - ALPHA or not ?
Date Wed, 02 Oct 2019 09:21:45 GMT
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
<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