accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Initial Release Plan for 2.0.0
Date Sat, 07 Jun 2014 16:40:40 GMT
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 <busbey@cloudera.com> 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 <ctubbsii@apache.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message