I'd like us to invest in unit tests and make them the contract guards. >
Thank you Jacek. In the end, I feel we strayed off the topic a bit - my question was quite > concrete - I'd like to remove the CASSANDRA_USE_JDK11 knob for CCM - it > should set it appropriately for Cassandra 4 so that the CCM user does not > have to bother. However, CCM should not use it to decide which Java version > to use. > +1 But note, this will be a breaking change for consumers still using CASSANDRA_USE_JDK11 as a way to use jdk11 over jdk8. > I'm unaware of any release cycle of CCM versions anywhere. Perhaps we > should do the following - tag a new version before the change and then add > the proposed change. > CCM does have versions. We should be using them more (releasing, and pinning explicit versions in the different requirements.txt instead of using the cassandra-test tag). The current version is 3.1.6 Maybe we can push a release of that so folk can pin it, and make these changes after that in a 3.2 And once ccm is donated we start at 4.0.0 > There are also other problems related to env setup - for example, when a > user or the dtest framework wants to force a certain Java version, it is > honored only for running a Cassandra node - it is not applied for running > nodetool or any other command line tool. Therefore, there is a broader > question about when the explicit Java version should be set - it feels like > the correct approach would be to set it up when a node is created rather > than when it is started so that the selection applies to running the server > and all the commands. > +1 What I would like to see is hardcoding of jdk versions removed from ccm. Today there's too many places where we have to touch code when a new C* version supports a new jdk. When it's only about the version number it's a bit nuts. We can't fix this for older C* versions, but from 5.1 we can now detect supported jdks whether it's the source or a binary.
