Oof, more to do, but I think the list you put together is a good plan to
start. Dropping all but LTS on major version sounds good as well.
Thanks for thinking about this already.
On 3/6/18 12:20 PM, Sean Busbey wrote:
Hi folks!
Our ref guide section on Java versions[1] is starting to look dated,
because the Oracle version of Java 9 hits end of public updates this
month and we don't mention it at all.
I'd like to discuss how we want to approach keeping HBase up-to-date
on new Java versions.
As background, the Java community is moving to a time-based release
schedule where there is a new long term support (LTS) version every
~three years[2]. Between those, there are a series of feature releases
that only have a short window of receiving updates.
-- "Recommended" for running
I think we should suggest folks rely on LTS releases of Java, wether
from the OpenJDK project (which looks like it will be equivalent to
the Oracle version) or a vender.
That would mean updating our support matrix to call out Java 9 and
Java 10 as "Not Supported" for current releases.
-- Development changes
The next LTS version of Java is slated to be Java 11, which won't be
out until September 2018. I think we should aim for a minor release on
whatever major branches are still active within a month of the GA date
where we feel comfortable calling out Java 11 as supported.
To that end, I think we would should do 2 things:
1) Work to make sure we can run through our test suite with either the
release prior to the next LTS or an early access version of the
upcoming LTS release before the GA date, ideally ~3 months before.
That'd be a target of June 2018 for the planned GA date of Java 11. I
expect that means abandoning our Java 9 specific efforts and starting
in April/May to work on updates related to Java 10 (or 11 depending on
when bits start shipping).
2) In the process of getting the above to work if we find we can't get
a major release branch ready to go without violating our compatibility
guidelines (especially wrt the existing supported java versions), we
should cease making new minor releases for that major release branch.
This could mean either just going to bugfix releases or it could mean
declaring the branch EOM entirely.
Note that the above doesn't necessarily require that we be able to
build with a newer JDK version. That would certainly be simpler
though; I don't think our current tooling makes it easy to run tests
with a different JDK than is used to compile.
-- Dropping of older versions
I don't think we've codified anywhere when we drop Java version
supports? (our guide merely says when we _could_.) I'm also not sure
if we should write it down somewhere? If we can stick to the above and
proactively add new versions as supported in minor releases, I think
we'll be in a good position to drop everything but the latest LTS Java
release with each HBase major release. Since this notion of LTS and
non-LTS releases for Java is still relatively new, maybe that's a
discussion we're better off having once HBase 3 is closer.
[1]: http://hbase.apache.org/book.html#java
[2]: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
