accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject RE: [VOTE] Plan for next release
Date Mon, 22 Aug 2016 22:35:29 GMT
2.0 is not released, so there is no burden.

Why do we need to maintain 1.6 or 1.7 as active? Why not eol and provide
actual testing and migration strategies to actually *deal* with the
maintenance burden instead of pushing it onto the users?

I would counter your question about tagging but not releasing with "why not
fix the packaging issues from rc2 and just make the release?"

With the amount of chatter on this vote thread, I am also now worried that
calling this vote was premature. These are discussions that should have
been hashed out already..

On Aug 22, 2016 18:23, <dlmarion@comcast.net> wrote:

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message