zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norbert Kalmar <nkal...@cloudera.com.INVALID>
Subject Re: Releasing 3.6.0 - ALPHA or not ?
Date Wed, 02 Oct 2019 09:03:51 GMT
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