accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [VOTE] Plan for next release
Date Mon, 22 Aug 2016 22:16:55 GMT
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