Thanks to Hannu and others pointing out that the OracleJDK is a *commercial* LTS, and thus not an option. mea culpa for missing the "commercial" and just focusing on the "LTS" bit. OpenJDK is is, then.
Stefan's elastic search link is rather interesting. Looks like they are compiling for both a LTS version as well as the current OpenJDK. They assume some of their users will stick to a LTS version and some will run the current version of OpenJDK. While it's extra work to add JDK version as yet another matrix variable in addition to our branching, is that something we should consider? Or are we going to burden maintainers even more? Do we have a choice? Note: I think this is similar to what Jeremiah is proposed. @Ariel: 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'm not sure we have a choice anymore, as we're basically bound to what the JDK developers choose to do (and we're bound to the JDK ...). However, if we have the changes necessary for the JDK releases higher than the LTS (if we following the elastic search model), perhaps it'll be a reasonably smooth transition? On Tue, Mar 20, 2018 at 1:31 PM, Jason Brown <jasedbr...@gmail.com> wrote: > 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 >> > >> > >> > >
