We should ensure that any of those in-progress / un-started features will be in a condition, by September-ish, that they can feasibly be left part-done or rolled back if needed. This would avoid delaying the timeline only because we passed the point of no return on a big feature, and it isn't done yet.
(If such a feature is deemed essential for a release, IMO a delay could be appropriate.) The time from code freeze to expected release is only two weeks and encompasses (U.S.) Thanksgiving. I heartily recommend extending it, say, to December 17, 2014 (four weeks). Other than that, looks good to me. Bill On Fri, Jun 6, 2014 at 2:35 PM, Christopher <[email protected]> wrote: > Devs, > > We've had several discussions around the idea that the next major release > to be 2.0.0, but we're still doing work and making tickets as though it's > going to be 1.7.0. I'd like to proceed with some initial actions that > formalizes this version bump to get things moving in that direction, with a > basic outline. We can modify this plan as needed, and if we later decide we > do want a 1.7.0 release, we can always create another release plan to fork > 1.6.x and apply the desired patches and release from there. > > According to the bylaws, a release plan is lazy consensus, unless vetoed, > in which case, we'd kick off a majority vote. With that in mind, the > following is my initial release plan for 2.0.0. > > Release Plan Actions for 2.0.0 (to be done on or around June 11, allowing > time to veto): > ===== > * Update version in git master branch from 1.7.0 to 2.0.0 > * Rename JIRA version 1.7.0 to 2.0.0 > > Initial anticipated features (from previous discussions/work): > ===== > * New client API (in progress) > * Replication (in progress) > * Drop support for Hadoop versions < 2.2 (not yet started) > * Drop support for Java < 1.7 (complete) > * Jetty 9 (ready to merge) > * More... (reply with additions to this list or use JIRA fixVersion to > identify issues) > > Contingency plan for incomplete features: > ===== > * Rollback, or clearly mark as experimental/beta, on a case-by-case basis. > > Release Manager: > ===== > * Initially, I'll volunteer, but I'm willing to pass it off or assist > somebody else, if they really wish to do it. > > Key dates: > ===== > * Feature Freeze - October 1, 2014 (create branch; no more feature merges, > minor API polishing/bugfixes only, full testing begins) > * Code Freeze - November 19, 2014 (no more polishing, bugfixes for blockers > identified in RCs only, RC1 is made) > * Expected Release - December 3, 2014 > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
