>> Don't forget that you have to spend bucks to get LTS. Huh? Is that true? Can you point me to any docs that I may have missed? That would be an important point to consider.
>> supporting Java 10 should be good enough. Sure but what about 2 years after we release a major, on a JDK that is 2-4 versions outdated? Are we going to get requests to keep upgrading/validating all 'live' versions under the JDK flavor of the month? That's what I'd like to avoid, if it's at all possible. On Tue, Mar 20, 2018 at 7:56 AM, Robert Stupp <sn...@gmx.de> wrote: > Don't forget that you have to spend bucks to get LTS. > > My hope is that after that Java 9, upcoming releases should be smoother to > use. I.e. settling the C* release on the Java release that's current at > that point in time sounds good enough. I.e. my hope is that any C* release > made for Java X will work with Java X+n (in the foreseeable future). Caveat > is probably the use of "Unsafe"... > > For example, if a major release would be planned for April, supporting > Java 10 should be good enough. But that C* major release should stay on > Java 10 and no code that requires a newer Java version must get in. > > I'm not sure whether recommending OracleJDK over OpenJDK is required. You > get some goodies with OracleJDK (CAs for example), sure. > > > On 03/20/2018 03:22 PM, Josh McKenzie 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-easi >>> er-use-and-redistribution-of-java-se >>> [3] >>> https://www.oracle.com/java/java9-screencasts.html?bcid=5582 >>> 439790001&playerType=single-social&size=events >>> [4] >>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.ht >>> ml?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 >> >> > -- > Robert Stupp > @snazy > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
