+1 on your suggestion, Sean.
Changing what 1.8 is at the 11th hour does not sit well with me. There
is no reason we cannot finish 1.8 as it stands, and then do the JDK8
switch for a 2.0 (and release it in whatever rapid succession is desired).
Sean Busbey wrote:
I'm all for moving us towards java 8+ only, but I'm still -1 on
dropping java 7 in a minor release. Plenty of folks still run Java 7
in production. I'm sure a non-zero number of them will want to update
versions and a major version is how we communicate that level of
expected disruption.
How about we get 1.8 out the door with Java 7 + Java 8, then try to
get master out the door with Java 8 as the minimum version? What's the
blocker on a release from master now?
On Thu, Aug 18, 2016 at 5:46 PM, Christopher<[email protected]> wrote:
We need to make sure this release works with Java 8 anyway... but this
change would tighten things up a bit, so we don't have to worry about
supporting Java 7. It narrows our testing and allows us to focus on just
the non-EOL, modern Java versions that we should be realistically expecting
users of Accumulo 1.8 to be using anyway.
On Thu, Aug 18, 2016 at 6:37 PM Josh Elser<[email protected]> wrote:
Err, I am not a big fan of making this change after two rc's and all of
the testing I've been babysitting this week.
I have no problem with you spinning a 2.0 which is 99% similar to 1.8
with whatever else you'd like to do (in fact, I'd encourage anyone to
step up and drive 2.0 to release).
Sean Busbey wrote:
Why don't we just make the 1.8 branch 2.0 then? I really don't want to
drop support for JDKs on non-major releases; it's super disruptive.
On Thu, Aug 18, 2016 at 4:01 PM, Christopher<[email protected]>
wrote:
I know we've talked about this before, but I kind of want to just use
Java
8 for Accumulo 1.8. It'd help clean up some things in the build (can
make
use of newer versions of build plugins, and make it easier for new
development against the latest release).
I just don't know how reasonable it is to keep making new, non-bugfix
releases on EOL JDKs (even though I may have previously argued that
it'd be
safer to just wait until a major version bump).
