Ok, I need to step back. I see that minJdk 8 was suggested but maybe not
using any new APIs for this proposed 2.0 release? This isn't 100% clear
to me at present. I will have to reread everything later tonight.
On Aug 22, 2016 18:49, "Josh Elser" <[email protected]
<mailto:[email protected]>> wrote:
(sorry posting from phone)
I missed the run jdk7 artifacts on jdk8 comment: I am not concerned
about this case (Oracle worries about it for me). I am worried about
jdk8 features being introduced in this hypothetical 2.0 which
preclude users from using jdk7 (for a primary reason of "I wanna us
new shiny APIs!" without concrete justification).
Christopher has so previously shared his concerns with me about
obtaining jdk7 packages from the internet. I do not think these are
valid concerns to present as justification for the change.
On Aug 22, 2016 18:35, "Josh Elser" <[email protected]
<mailto:[email protected]>> wrote:
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, <[email protected]
<mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>]
On Behalf Of
> Josh Elser
> Sent: Monday, August 22, 2016 6:17 PM
> To: [email protected] <mailto:[email protected]>
> 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" <[email protected]
<mailto:[email protected]>> wrote:
>
> > -1
> >
> > On Aug 22, 2016 17:22, "Christopher"
<[email protected] <mailto:[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)
> >>
> >
