On 25 June 2014 17:07, Patrick Hunt <[email protected]> wrote: > Hey folks, we've been talking about it for a while, a few people have > mentioned on the list as well as contacted me personally that they > would like to see some progress on the first 3.5 release. Every > release is a compromise, if we wait for perfection we'll never get > anything out the door. 3.5 has tons of great new features, lots of > hard work, let's get it out in a release so that folks can use it, > test it, and give feedback. > > Jenkins jobs have been pretty stable except for the known flakey test > ZOOKEEPER-1870 which Flavio committed today to trunk. Note that > jenkins has also been verifying the code on jdk7 and jdk8. > > Here's my thinking again on how we should plan our releases: > > I don't think we'll be able to do a 3.5.x-stable for some time. What I > think we should do instead is similar to what we did for 3.4. (this is > also similar to what Hadoop did during their Hadoop 2 release cycle) > Start with a series of alpha releases, something people can run and > test with, once we address all the blockers and feel comfortable with > the apis & remaining jiras we then switch to beta. Once we get some > good feedback we remove the alpha/beta moniker and look at making it > "stable'. At some later point it will become the "current/stable" > release, taking over from 3.4.x. > > e.g. > 3.5.0-alpha (8 blockers) > 3.5.1-alpha (3 blockers) > 3.5.2-alpha (0 blockers) > 3.5.3-beta (apis locked) > 3.5.4-beta > 3.5.5-beta > 3.5.6 (no longer considered alpha/beta but also not "stable" vs 3.4.x, > maybe use it for production but we still expect things to shake out) > 3.5.7 > .... > 3.5.x - ready to replace 3.4 releases for production use, stable, etc... > > There are 8 blockers currently, are any of these something that should > hold up 3.5.0-alpha? > > I'll hold open the discussion for a couple days. If folks find this a > reasonable plan I'll start the ball rolling to cut an RC. > > sgtm, +1.
-rgs
