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
-
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 sugge
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 consen
On Wed, Oct 2, 2019 at 2:22 AM Enrico Olivelli 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 compati
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
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 = ne
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
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 wrote:
>
> I am leaning towards release master as 3.6.0 as well, not with any
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-use
Enrico these are good ideas, thoughts below:
On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar
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 fin
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 min
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 S
12 matches
Mail list logo
