+1 to that, too
Dave Marion wrote:
It's 2.0, remove mock and deprecate it in 1.8 if it's not already.
On May 6, 2016 10:25 AM, "Josh Elser"<[email protected]> wrote:
We can't disable modernizer just for mock? Or really, any code which we
intentionally don't want to modernize?
On May 5, 2016 11:43 PM, "Christopher"<[email protected]> wrote:
Another interesting point... didn't realize until actually doing it:
bumping to JDK8 *requires* a bump in the major version, because modernizer
will block on some incompatible API changes in Mock, which is already
deprecated. (Unless we're okay with disabling modernizer... which I guess
is an acceptable solution... but it makes me unhappy :) )
On Thu, May 5, 2016 at 11:39 PM Josh Elser<[email protected]> wrote:
Thanks boss. I figured you'd have my back :)
On May 5, 2016 9:43 PM, "Christopher"<[email protected]> wrote:
Already pushed. Initially forgot about modernizer, but I'm working
through
it now.
On Thu, May 5, 2016 at 7:25 PM Josh Elser<[email protected]>
wrote:
Sounds good!
I had tried to switch master to jdk8 as well, but ran into
modernizer
plugin issues. I've since been on a call, so I haven't been able to
push
that update. I'll get to it when I can, but perhaps someone has
beaten
me to it already.
Christopher wrote:
Okay, so if we're okay treating the master branch as a 2.0
development
branch, then I'm going to go ahead and start focusing on some 2.0
tickets
that may involve refactoring which have breaking changes that I've
been
reluctant to do before without an explicit 2.0 development branch.
Of
course, none of this says we have to stop development on 1.x
stuffs,
or
says anything about when we'll release a 2.0, but it'd be nice to
have
a
place to start putting in stuff for an eventual 2.0.
On Thu, May 5, 2016 at 11:07 AM Josh Elser<[email protected]>
wrote:
Ok, looks to me that we are in agreement now and don't need a
vote.
I will create a 1.8 branch today (updating Jenkins appropriately)
so
we
can get master in a state that would be ready for the changes in
4177.
Keith Turner wrote:
On Tue, May 3, 2016 at 4:54 PM, Christopher<[email protected]>
wrote:
I think I'd prefer leaving 1.8 as it stands, with the
expectation
to
have a
release line of 1.8 which only requires Java 7.
+1
I can not see any reason to switch to JDK8 before releasing
1.8...
assuming
thats going to happen soonish
We can create a 2.0 branch, which bumps the Java version, and
can
accept
changes which require Java 8 or API-breaking changes (as per
semver)
for
the next major release line after 1.8.
That would put us on a solid roadmap for 2.0 without disrupting
1.8
development, which is probably already nearing release
readiness.
On Tue, May 3, 2016 at 4:33 PM Josh Elser<[email protected]>
wrote:
Gotcha. Thanks for clarifying, Mike -- I'm inclined to agree
with
you.
I
can't think of a reason why we would upgrade to Java8 and not
make
use
of it in some way (publicly or privately).
That being said, I don't think I see consensus. How about we
regroup
in
the form of a vote? (normal semver rules are an invariant --
no
changes
to our public API compatibility rules are implied by the
below)
* Call the current 1.8.0-SNAPSHOT (master) "2.0.0-SNAPSHOT"
and
move
to
jdk8
* Branch 1.8, make master 2.0.0-SNAPSHOT. 1.8 stays jdk7, 2.0
goes
jdk8
Please chime in if I missed another option or am calling
discussion
too
soon. It just seems like we might have veered off-track and I
don't
want
this to fall to the wayside (again) without decision.
Mike Drob wrote:
If our code ends up using java 8 bytecode in any classes
required
by a
consumer, then I think they will get compilation (linking?)
errors,
regardless of java 8 types in our methods signatures.
On Tue, May 3, 2016 at 3:09 PM, Josh Elser<
[email protected]
wrote:
That's a new assertion ("we can't actually use Java 8
features
util
Accumulo-2"), isn't it? We could use new Java 8 features
internally
which
would require a minimum of Java 8 and not affect the public
API.
These
are
related, not mutally exclusive, IMO.
To Shawn's point: introducing Java 8 types/APIs was exactly
the
point
--
we got here from ACCUMULO-4177 which does exactly that.
Mike Drob wrote:
I agree with Shawn's implied statement -- why bother
dropping
Java 7
in
any
Accumulo 1.x if we can't actually make use of Java 8
features.until
Accumulo 2.0
On Tue, May 3, 2016 at 1:29 PM, Christopher<
[email protected]
wrote:
Right, these are competing and mutually exclusive goals, so
we
need
to
decide which is a priority and on what timeline we should
transition
to
Java 8 to support those goals.
On Tue, May 3, 2016 at 9:16 AM Shawn Walker<
[email protected]
wrote:
I'm not sure that guaranteeing build-ability under Java 7
would
address
the
issue that raised this discussion: We (might) want to
add a
dependency
which requires Java 8. Or, following Keith's comment, we
might
wish
to
introduce Java 8 types (e.g. CompletableFuture<T>) into
Accumulo's
"public"
API.
On Mon, May 2, 2016 at 6:42 PM, Christopher<
[email protected]
wrote:
I don't feel strongly about this, but I was kind of
thinking
that
we'd
bump
to Java 8 dependency (opportunistically) when we were
ready
to
develop
a
2.0 version. But, I'm not opposed to doing it on the 1.8
branch.
On Mon, May 2, 2016 at 2:50 PM William Slacum<
[email protected]>
wrote:
So my point about versioning WRT to the Java runtime is
more
about
how
there are incompatibilities within the granularity of
Java
versions
we
talk
about (I'm specifically referencing a Kerberos
incompatibility
within
versions of Java 7), so I think that just blanket
saying
"We
support
Java X
or Y" really isn't enough. I personally feel some kind
of
version
bump
is
nice to say that something has changed, but until the
public
API
starts
exposing Java 8 features, it's a total cop out to say,
"Here's
all
these
bug fixes and some new features, oh by the way upgrade
your
infrastructure
because we decided to use a new Java version for an
optional
feature".
The best parallel I can think of is in Scala, where
there's
no
binary
compatibility between minor versions (ie, 2.10,
2.11,etc),
so
there's
generally an extra qualifier on libraries marking the
scala
compability
level. Would we ever want to have
accumulo-server-1.7-j[7|8]
styled
artifacts to signal some general JRE compatibility?
It's a
total
mess,
but
I haven't seen a better solution.
Another idea is we could potentially have some
guarantee
for
Java
7,
such
as making sure we can build a distribution using Java 7,
but
only
distribute Java 8 artifacts by default?
On Mon, May 2, 2016 at 2:30 PM, Josh Elser<
[email protected]
wrote:
Sean Busbey wrote:
On Mon, May 2, 2016 at 8:55 AM, Josh Elser<
[email protected]
wrote:
Thanks for the input, Sean.
Playing devil's advocate: we didn't have a
major
version
bump
when
we
dropped JDK6 support (in Accumulo-1.7.0). Oracle
has
EOL'ed
java 7
back in
April 2015. Was the 6->7 upgrade different
than
a
7->8
upgrade?
On Mon, May 2, 2016 at 10:31 AM, Keith Turner<
[email protected]>
wrote:
On Mon, May 2, 2016 at 1:54 AM, Sean Busbey<
[email protected]
wrote:
If we drop jdk7 support, I would strongly
prefer
a
major
version
bump.
Whats the rationale for binding a bump to
Accumulo
2.0
with
a
bump
in
the
JDK version?
The decision to drop JDK6 support happened in
latemarch /
earlyApril
2014[1], long before any of our discussions or decisions
on
semver.
AFAICT it didn't get discussed again, presumably because
by
the
time
we got to 1.7.0 RCs it was too far in the past.
Thanks for the correction, Sean. I hadn't dug around
closely
enough.
