> -- "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.

+1 for at least calling out Java 9 and Java 10 as "Not Tested" (Not
Supported if we know for sure it won't work).

As for recommending folks rely on LTS releases, I think this will require a
shift in thinking
from most people in the Hadoop ecosystem to upgrade the Java versions more
Otherwise it will become a pain for users to use multiple open source
projects in the same
environment (for example if Hadoop is using Java 8, Spark - Java 9, and
HBase - Java 11).
Not saying that we should hold ourselves back because of other projects,
but we should
at least consider the burden.

I do, however, think that long term we should only recommend running with
the current LTS release.
Getting there might be a lot of fun though :)

> -- 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).
+1, doesn't make sense doing work that will be already be obsolete by this
desired direction.

> 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.

I don't see this happening before 3.0 anyways. Let's work on getting 1)
done for Java 9/10.
I think we should wait until we see how this is all going to pan out (and
how much work each upgrade will be)
before making anything public, but I think this is a good goal.

Thanks for writing this up,

Reply via email to