You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Enrico Olivelli <eo...@gmail.com> on 2019/10/01 12:26:03 UTC
Releasing 3.6.0 - ALPHA or not ?
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
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
The 3.5.x-ALPHA scheme was extremely confusing for ZK's user base (doubly so given how long it remained in alpha then beta). Many companies used it anyway so adding the qualifier didn't serve much purpose. Better to leave it off and communicate known issues through standard channels.
My 0.02
-Jordan
> On Nov 15, 2019, at 3:52 PM, Fangmin Lv <lv...@gmail.com> wrote:
>
> I like the idea of keeping the naming simple and getting rid of 3.6.x. And
> it seems reasonable
> to me to keep beta for a while before we make it a 'stable' version even
> though for the features
> or fixes contributed from different individuals/orgs may have run on their
> prod for a while.
>
> I would suggest to cut 3.7.0 for the next branch, and only bump major
> version if there is a real
> big and non-compatible change we'd like to release.
>
> Best,
> Fangmin
>
>
> On Wed, Oct 2, 2019 at 9:00 AM Zili Chen <wa...@gmail.com> wrote:
>
>> 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 <eo...@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
>>>> <nk...@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 <ha...@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
>>>>>> <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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Fangmin Lv <lv...@gmail.com>.
I like the idea of keeping the naming simple and getting rid of 3.6.x. And
it seems reasonable
to me to keep beta for a while before we make it a 'stable' version even
though for the features
or fixes contributed from different individuals/orgs may have run on their
prod for a while.
I would suggest to cut 3.7.0 for the next branch, and only bump major
version if there is a real
big and non-compatible change we'd like to release.
Best,
Fangmin
On Wed, Oct 2, 2019 at 9:00 AM Zili Chen <wa...@gmail.com> wrote:
> 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 <eo...@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
> > > <nk...@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 <ha...@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
> > > > > <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
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Zili Chen <wa...@gmail.com>.
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 <eo...@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
> > <nk...@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 <ha...@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
> > > > <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
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Oct 2, 2019 at 2:22 AM Enrico Olivelli <eo...@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
> <nk...@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 <ha...@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
> > > <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
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Andor Molnar <an...@apache.org>.
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 <eo...@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 ?
>
> 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
> <nk...@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 <ha...@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
>>> <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 <eo...@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
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Enrico Olivelli <eo...@gmail.com>.
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
<nk...@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 <ha...@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
> > <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 <eo...@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
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Norbert Kalmar <nk...@cloudera.com.INVALID>.
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 <ha...@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
> <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 <eo...@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
> >>>>
> >>>
> >>
>
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Andor Molnar <an...@apache.org>.
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 <ha...@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 <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 <eo...@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
>>>>
>>>
>>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Michael Han <ha...@apache.org>.
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 <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 <eo...@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
> > >
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Patrick Hunt <ph...@apache.org>.
Enrico these are good ideas, thoughts below:
On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar <nk...@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 <eo...@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
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Norbert Kalmar <nk...@cloudera.com.INVALID>.
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).
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 :)
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 <eo...@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
>