bq. Dropping all but LTS on major version +1 to the above initiative.
On Thu, Mar 8, 2018 at 8:37 AM, Josh Elser <els...@apache.org> wrote: > 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-Septembe >> r/004281.html >> >>
