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. Patrick
