copied directly from dev channel, just to keep with this ML conversation 08:08:26 <snazy> Robert Stupp jasobrown: https://www.azul.com/java-stable-secure-free-choose-two-three/ and https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se 08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial long term support offering" 08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html 08:09:21 the keyword in that cite is "commercial" 08:21:21 <exlt> Michael Shuler a couple more thoughts.. 1) keep C* support in step with latest Ubuntu LTS OpenJDK major in main, 2) bundle JRE in C* releases? (JDK is not "legal" to bundle) 08:23:44 <spodkowinski> https://www.elastic.co/blog/elasticsearch-java-9-and-beyond - interesting read on that matter 08:26:04 can't wait for the infra and CI testing implications.. will be lot's of fun ;( 08:42:13 <snazy> Robert Stupp Not sure whether stepping with Ubuntu is necessary. It's not so difficult to update apt.source ;) 08:42:43 CI ? It just let's your test matrix explode - a litte ;) 08:46:48 <exlt> Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8 (latest)'` in job DSL and could easily modify that
On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali <k...@peernova.com> wrote: > Java 10 is releasing today! > > On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > > > +1 to what Jordan is saying. > > > > It seems like if we are cutting a release off of trunk we want to make > > sure we get N years of supported JDK out of it. For a single LTS release > N > > could be at most 3 and historically that isn't long enough and it's very > > likely we will get < 3 after a release is cut. > > > > Going beyond 3 years could be tricky in the worst case because bringing > in > > up to 3 years of JDK changes to an older release might mean some of our > > dependencies no longer function and now it's not just minor fixes it's > > bringing in who knows what in terms of updated dependencies. > > > > I think in some cases we are going to need to take a release we have > > already cut and make it work with an LTS release that didn't exist when > the > > release was cut. > > > > We also need to update how CI works. We should at least build and run a > > quick smoke test with the JDKs we are claiming to support and > > asynchronously run all the tests on the rather large matrix that now > exists. > > > > Ariel > > > > On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote: > > > My suggestion would be to keep trunk on the latest LTS by default, but > > > with compatibility with the latest release if possible. Since Oracle > > > LTS releases are every 3 years, I would not want to tie us to that > > > release cycle? > > > So until Java 11 is out that would mean trunk should work under Java 8, > > > with the option of being compiled/run under Java 9 or 10. Once Java 11 > > > is out we could then switch to 11 only. > > > > > > -Jeremiah > > > > > > On Mar 20, 2018, at 10:48 AM, Jason Brown <jasedbr...@gmail.com> > wrote: > > > > > > >>> Wouldn't that potentially leave us in a situation where we're ready > > for > > > > a C* release but blocked waiting on a new LTS cut? > > > > > > > > Agreed, and perhaps if we're close enough to a LTS release (say three > > > > months or less), we could choose to delay (probably with community > > > > input/vote). If we're a year or two out, then, no, we should not > wait. > > I > > > > think this is what I meant to communicate by "Perhaps we can evaluate > > this > > > > over time." (poorly stated, in hindsight) > > > > > > > >> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie < > jmcken...@apache.org> > > wrote: > > > >> > > > >> Need a little clarification on something: > > > >> > > > >>> 2) always release cassandra on a LTS version > > > >> combined with: > > > >>> 3) keep trunk on the lasest jdk version, assumming we release a > major > > > >>> cassandra version close enough to a LTS release. > > > >> > > > >> Wouldn't that potentially leave us in a situation where we're ready > > > >> for a C* release but blocked waiting on a new LTS cut? For example, > if > > > >> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd > > > >> either have to get trunk to work with 9 or wait for 11 to resolve > > > >> that. > > > >> > > > >>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown <jasedbr...@gmail.com > > > > wrote: > > > >>> Hi all, > > > >>> > > > >>> > > > >>> TL;DR Oracle has started revving the JDK version much faster, and > we > > need > > > >>> an agreed upon plan. > > > >>> > > > >>> Well, we probably should has this discussion this already by now, > but > > > >> here > > > >>> we are. Oracle announced plans to release updated JDK version every > > six > > > >>> months, and each new version immediate supercedes the previous in > all > > > >> ways: > > > >>> no updates/security fixes to previous versions is the main thing, > and > > > >>> previous versions are EOL'd immediately. In addition, Oracle has > > planned > > > >>> parallel LTS versions that will live for three years, and then > > superceded > > > >>> by the next LTS; but not immediately EOL'd from what I can tell. > > Please > > > >> see > > > >>> [1, 2] for Oracle's offical comments about this change ([3] was > > > >>> particularly useful, imo), [4] and many other postings on the > > internet > > > >> for > > > >>> discussion/commentary. > > > >>> > > > >>> We have a jira [5] where Robert Stupp did most of the work to get > us > > onto > > > >>> Java 9 (thanks, Robert), but then the announcement of the JDK > version > > > >>> changes happened last fall after Robert had done much of the work > on > > the > > > >>> ticket. > > > >>> > > > >>> Here's an initial proposal of how to move forward. I don't suspect > > it's > > > >>> complete, but a decent place to start a conversation. > > > >>> > > > >>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK > will > > > >>> release every six months, and the OracleJDK will release every > three > > > >> years. > > > >>> Thus, the OracleJDK is the LTS version, and it just comes from a > > snapshot > > > >>> of one of those OpenJDK builds. > > > >>> > > > >>> 2) always release cassandra on a LTS version. I don't think we can > > > >>> reasonably expect operators to update the JDK every six months, on > > time. > > > >>> Further, if there are breaking changes to the JDK, we don't want to > > have > > > >> to > > > >>> update established c* versions due to those changes, every six > > months. > > > >>> > > > >>> 3) keep trunk on the lasest jdk version, assumming we release a > major > > > >>> cassandra version close enough to a LTS release. Currently that > seems > > > >>> reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS) > > > >>> support. Perhaps we can evaluate this over time. > > > >>> > > > >>> > > > >>> Once we agree on a path forward, *it is impreative that we publish > > the > > > >>> decision to the docs* so we can point contributors and operators > > there, > > > >>> instead of rehashing the same conversation. > > > >>> > > > >>> I look forward to a lively discussion. Thanks! > > > >>> > > > >>> -Jason > > > >>> > > > >>> [1] http://www.oracle.com/technetwork/java/eol-135779.html > > > >>> [2] > > > >>> https://blogs.oracle.com/java-platform-group/faster-and- > > > >> easier-use-and-redistribution-of-java-se > > > >>> [3] > > > >>> https://www.oracle.com/java/java9-screencasts.html?bcid= > > > >> 5582439790001&playerType=single-social&size=events > > > >>> [4] > > > >>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live. > > > >> html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ > > > >> StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29 > > > >>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608 > > > >> > > > >> ------------------------------------------------------------ > --------- > > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > >> > > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
