[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695896#comment-17695896 ]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/2/23 9:00 PM: ------------------------------------------------------------------------- I am thinking - if we consider Java 8 breaking change, then I would expect we don't change JDKs but we test the paths with 8 and then when we remove 8, we test those that are capable of handling 11. Considering we agreed as a community to maintain three versions at a time (with exception for 3.0) this sounds almost already limiting to testing adjacent versions. But let's consider if those were 4, 5, 6 (ignore 4.1 for a moment which someone will say it is minor) and they all run with Java 11, we are not going to test the upgrade from 4 to 6? So the way I understand is that whatever is the common JDK version dictates to some extend the upgrade path. Our upgrade tests also follow the upgrade paths people will take. So I guess we consider people are on Java 8 upgrading from 3.11 to 4.1. Then they switch to 11 and then they upgrade to 5? While we have only JAVA_HOME how would we have such a complete test? I _guess_ that was the past goal having those separate JAVAX_HOME, no? To be able to exercise the whole path and not stop on certain version and separately test that version upgrade etc? Just trying to create a proper mental model and not to miss anything. As I fear I do miss something... was (Author: e.dimitrova): I am thinking - if we consider Java 8 breaking change, then I would expect we don't change JDKs but we test the paths with 8 and then when we remove 8, we test those that are capable of handling 11. Considering we agreed as a community to maintain three versions at a time (with exception for 3.0) this sounds almost already limiting to testing adjacent versions. But let's consider if those were 4, 5, 6 (ignore 4.1 for a moment which someone will say it is minor) and they all run with Java 11, we are not going to test the upgrade from 4 to 6? So the way I understand is that whatever is the common JDK version dictates to some extend the upgrade path. Our upgrade tests also follow the upgrade paths people will take. So I guess we consider people are on Java 8 upgrading from 3.11 to 4.1. Then they switch to 11 and then they upgrade to 5? While we have only JAVA_HOME how would we have such a complete test? I _guess_ that was the past goal having those separate JAVAX_HOME, no? To be able to exercise the whole path and not stop on certain version and separately test that version etc? Just trying to create a proper mental model and not to miss anything. > Update CCM for JDK17 and revise current JDK detection strategy > -------------------------------------------------------------- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI > Reporter: Ekaterina Dimitrova > Assignee: Brandon Williams > Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org