+1 to move to 2.0 unless you plan on naming the release after me. On Mon, Aug 22, 2016 at 5:24 PM, Christopher <[email protected]> wrote:
> My vote is +1, because I don't think we *need* an extra release line named > 1.8, when a 2.0 release from master will suffice, and in particular because > of the backwards-compatibilities it will have with 1.7/1.6. > > On Mon, Aug 22, 2016 at 5:21 PM Christopher <[email protected]> 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) > > > > >
