I propose we:
- Exclude JDK support from the subject of this vote.
- And start a separate [DISCUSS] and [VOTE] thread to cover JDK/JRE lifecycle.
Josh’s proposal that we are voting on does not address JDK versioning, and I don’t interpret the text of the proposal as a referendum on it. Many / most did not seem to have JDK versioning in mind when voting on a policy concerning feature lifecycle and user-visible API surface.
I see the point on JDK-as-interface, but I think we can make meaningful forward progress on feature/API lifecycle if we bracket runtime as a separate topic.
– Scott On Apr 23, 2025, at 9:04 PM, Joseph Lynch <joe.e.ly...@gmail.com> wrote:
Isn't the JDK we build with when publishing to maven somewhat of a public interface due to cassandra-all library usage? I agree that we probably just need to clearly document what JVMs we test a release on which is a good signal for what we think will work at runtime (and this may be a much newer JVM than we built with).
Apologies I didn't intend to change what we were voting on, I was just trying to understand if we were voting on the original text or the original text plus the "we don't break things and discuss breakage before breaking apis" (which I still can't find on the wiki, but I am likely just bad at search).
I do agree version and feature support is perhaps a separate topic from killing the minor (which seems unambiguously good).
-Joey
Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* you're testing to both support running on (and probably right now building on) a shared JDK version. So for instance, if we had:
- Release 21.0.0: JDK30, JDK31 - Release 22.0.0: JDK35, JDK40
We wouldn't be able to test an upgrade from 21 to 22. Arguably we could build on an older supported version and run both on the newer, but at least right now I think that's our restriction. There's tension here if our release cadence and LTS JDK's intersect badly, but JDK LTS is infrequent enough relative to our releases that I think we're potentially getting worked up about a non-issue here.
Since the JDK isn't an API and we've already discussed and have some measure of consensus in the past (I thought; haven't dug that up now due to shortage of time), I think we can and should formalize that separately from this vote thread.
On Wed, Apr 23, 2025, at 6:31 PM, David Capwell wrote: Also, I thought we had separate discussion about them - that we want to keep up possibly with the last two LTS versions.
This is what I remember as well. 6.0 would support 17/21 as thats the latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25
I should say that I also haven’t thought of JDK versions when I voted here. Also, I thought we had separate discussion about them - that we want to keep up possibly with the last two LTS versions. Currently we do not have vision on when will be the next release date, so I cannot personally align JDK LTS versions to our versioning. Also, depends on people availability and testing resources when and what versions we will maintain our builds with. (And when and what Cassandra releases we will have, too)
Regarding the - “do not change what we vote for in the middle of the vote” - I agree, this is not the way to do it. But honestly I did not perceive this voting as such a case. I also knew about the agreement that any breaking changes will be discussed on the dev mailing list prior removal and we try to be backward compatible as much as possible.
> The JVM version also isn’t a feature to deprecate, technically. I agree with this. I think the JVM version the server runs under and how we cycle those is a separate discussion from feature deprecation.
There can and has been some overlap there that would need to be handled on a case by case basis (when a new JVM removed something that we did not have a good way to keep doing without it, talking about you scripting runtime based UDFs), but in general I don’t think switching JVMs is the same as feature removal/deprecation.
-Jeremiah
I agree with Jon that I’m now a bit confused on part of what I voted for. It feels like there is more discussion to be had here. Or we need to split it into two votes if we want to make progress on the part where there is consensus and revisit where there is not.
Regarding JVM version what I’ve mostly seen as reasons against forcing a JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades have a tendency to want to limit as many variables as possible. From a technical perspective I’m not sure that’s justified tbh but having been one of the folks wanting to reduce variables and still getting bit by upgrades I understand it. The JVM version also isn’t a feature to deprecate, technically. And having made the decision once to hold off on upgrading the JVM and regretting it I too would like to see the project try to keep pace with JVM releases instead of being on older LTS or unsupported versions.
Jordan
> If 5.0 supports 17, then 7.0 should too, if we are to say we support 5.0 to 7.0 upgrades.
I have to disagree with this. I don't see a good reason have a tight coupling of JVM versions to C* versions, and I also don't see a good reason to overlap outside of CI. Even on CI, the reasoning is a bit weak, Linux distros have supported multiple JDK versions for at least a decade (update-java-alternatives on Ubuntu and alternatives on RedHat).
I've heard several folks explain their reasoning for overlap in JVM versions, and it just doesn't resonate with me when weighed against the downsides of being anchored to the limitations imposed by supporting old JVM versions.
I don't want this to come back and bite us later - so unless we're exempting the JVM version from this upgrade requirement, I'm changing my vote to -1.
Furthermore, really shouldn't be changing the terms of the thing we're voting on mid-vote. This feels really weird to me. Anyone who cast a vote previously may not be keeping up with the ML on a daily basis and it's not fair to impose changes on them. People should be aware of what they're voting for and not be surprised when the VOTE is closed.
. This reads to me that Java 17 would need to be deprecated now, continue to be deprecated in 6.0 (at least one major in deprecated), then removed in 7.0.
This is technically true. But I don't think we need to be explicitly deprecating jdk versions. Users are generally aware of Java's LTS cycle, and we can document this separately.
Where we are bound is that our upgrade tests require an overlapping common jdk. So we can only test upgrades that support a common jdk. And 🥁 IMHO, we should not be saying we recommend/support upgrades that we don't test (regardless if not having broken compatibility means we think untested upgrade paths would still work). If 5.0 supports 17, then 7.0 should too, if we are to say we support 5.0 to 7.0 upgrades.
|
