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
