Re: feature status, September is a good time for the release manager to start checking on feature readiness, and for the community to discuss alterations to the release's final feature set.
Re: Thanksgiving, that's a good point, but I expect the efforts during that time to be mostly RC voting, not development, so I think it's fine for an initial date. Release voting may take longer, and we can extend if needed. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Jun 6, 2014 at 4:25 PM, Bill Havanki <[email protected]> wrote: > 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 >
