accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <dlmar...@comcast.net>
Subject RE: [VOTE] Plan for next release
Date Mon, 22 Aug 2016 22:23:38 GMT
I share your concerns and have proposed releasing a 1.8.0 as-is, followed by a 2.0 with much
the same artifacts plus Java 8 source. In talking with Christopher about this though, that
means that the community would be supporting 1.6 (until 1.6.6 is released), 1.7.x, 1.8.x,
and 2.0.x. Being on update 102, Java 8 seems pretty stable. Plus, you can run your Java 7
binaries with the Java 8 JRE.

Having said that, is there a reason that we can't tag 1.8.0 but not release it and let other
downstream providers create their own supported release?

> -----Original Message-----
> From: josh.elser@gmail.com [mailto:josh.elser@gmail.com] On Behalf Of
> Josh Elser
> Sent: Monday, August 22, 2016 6:17 PM
> To: dev@accumulo.apache.org
> Subject: Re: [VOTE] Plan for next release
> 
> Mike Wall asked if I could expand. I realized that my objections were
> probably only in IRC with Christopher and didn't get cross-posted. I had
> thought that they were already present in the discussion thread.
> 
> 1. 1.8.0 is practically released already as-is. I spent a good chunk of the last
> week babysitting tests. This change feels no different than someone shoe-
> horning in a big feature at the last minute.
> 
> 2. I think this is a slap in the face to anyone that was waiting on a 1.8.0 to be
> released as slap in the face. The release that was about to happen now has
> an even longer cycle.
> 
> 3. Assuming that min jdk 8 also implies use of jdk 8 only features (as was
> mentioned), my experience with customer bases is that people are not yet
> there. Often, these groups do have migration plans in place, but I haven't
> seen one that has a quicker than one year turnaround. I cannot back any of
> this up with fact, it is merely observations from my day job.
> 
> I do not find the provided reasons to make this last minute change
> justification enough to do it. I am very much against it.
> 
> On Aug 22, 2016 17:58, "Josh Elser" <elserj@apache.org> wrote:
> 
> > -1
> >
> > On Aug 22, 2016 17:22, "Christopher" <ctubbsii@apache.org> wrote:
> >
> >> After our lengthy (sorry for that) discussions about Java 8, 1.8.0,
> >> and 2.0.0, I wanted to bring us to a vote, just so we can have a
> >> concrete plan of action, without any ambiguity or uncertainty. A vote
> >> is the best option available for resolving differences of opinion
> >> about our upcoming release plans.
> >>
> >> The action to vote on is the following:
> >>
> >>     (+1): Drop 1.8 branch, stabilize the master branch, and release
> >> 2.0.0 from master
> >>
> >> If the vote fails to pass, the default action (which is implied by a
> >> -1) is the following:
> >>
> >>     (-1): Release 1.8.0, supporting a 1.8.x release series; 2.0.0 and
> >> the master branch will be addressed at some unspecified future time
> >>
> >> This is a majority vote regarding release plans, so we can make
> >> progress on a reasonable release timeline. Specific changes in a
> >> branch can still be veto'd while we work towards the release, as
> >> normal, regardless of the outcome of this vote.
> >>
> >> Here's some main points to consider for this vote:
> >>
> >> * Everything in the 1.8 branch is included in the Master branch.
> >> * Master branch requires Java 8.
> >> * Releasing from master will allow us to work from master again for
> >> routine development, instead of reserving master for unstable
> >> development (which is how it currently has been treated).
> >> * Master branch aggressively removes deprecated stuffs; I'm actively
> >> working on reverting these in master regardless of the vote, because
> >> they introduced some destabilization.
> >> * The one deprecation removal which I intend to keep in Master is the
> >> removal of the trace library (not the tracer server, which will
> >> stay). We don't need the trace library, because we now use HTrace. If
> >> people need the deprecated HTrace wrappers for their own code in that
> >> trace library, they should still be able to use the wrappers in the
> >> 1.7 version of accumulo-trace. They won't need it for Accumulo,
> >> though, because Accumulo doesn't use it, not even in the 1.7 branch.
> >> This would be added to the release notes if this vote passes.
> >> * After reverting the deprecation removals, the master branch is
> >> *very* similar to the 1.8 branch right now. It contains only a few
> >> extra commits, mostly for Java 8-related cleanups and README
> >> improvements. (git log origin/1.8..origin/master --no-merges
> >> --oneline)
> >> * If this vote passes, it will be 100%, or nearly 100%,
> >> backwards-compatible with 1.7.x, just as 1.8 branch is today. This is
> >> because there haven't been much changes in the master branch which
> >> aren't coming from merges from 1.8. This will mean that the entire
> >> 2.x line will be just as backwards-compatible as this next release
> >> and there will be no significant deprecation removals from [1.7.0, 3.0).
> >>
> >> This vote will end on Thu Aug 25 21:30:00 UTC 2016 (Thu Aug 25
> >> 17:30:00 EDT 2016 / Thu Aug 25 14:30:00 PDT 2016)
> >>
> >


Mime
View raw message