I'd consider the compatibility statement a blocker for the release, but not a blocker for the release plan.
I said 2.2, because the only Hadoop releases prior to that in the 2.x series are alpha/beta releases... and I wouldn't want to have to maintain compatibility with alpha/beta releases. It may be that those would work just fine... I just don't want to make it a goal. Given our past history of releases, I think Sept 12 would be *way* too optimistic. This timeline is already shorter than the 1.6 one, but I want to be practical. If things go more rapidly than we expect, we can release earlier, but I'd rather not impose an artificial rush on things. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sat, Jun 7, 2014 at 10:33 AM, Sean Busbey <[email protected]> wrote: > I would like to have a formally adopted compatibility statement as a > condition of the 2.0.0 release. > > In previous discussion, I thought we had only talked about dropping support > for Hadoop 1. Is there a particular reason you're looking to specifically > make 2.2.0 our minimum version? > > What are we expecting to get done between each of the freeze dates? I'd > expect the bulk of release testing to be between feature freeze and code > freeze. And I'd expect the time between code freeze and release to be spent > on docs / packaging. If this lines up with everyone else's expectations, I > think the original deltas between each date look reasonable. > > Since this release is going to be breaking, I'm inclined to favor fewer > features with a sooner release date. The idea would be that this would give > those who need to develop against our APIs earlier access to get started. > We can always add in more features in a subsequent minor release. > > What about aiming for a release date of Sep 12, to line up with the > anniversary of our start in the incubator? That would put feature freeze at > ~July 12 and code freeze at Aug 29th. > 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 >
