accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: Initial Release Plan for 2.0.0
Date Sat, 07 Jun 2014 14:33:18 GMT
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