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


On Wed, Apr 23, 2025 at 7:47 PM Josh McKenzie <jmcken...@apache.org> wrote:

> 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
>
> On Apr 23, 2025, at 3:11 PM, Ekaterina Dimitrova <e.dimitr...@gmail.com>
> wrote:
>
> 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.
>
> On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan <jerem...@apache.org> wrote:
>
> > 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
>
>
> On Wed, Apr 23, 2025 at 4:48 PM Jordan West <jw...@apache.org> wrote:
>
> 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
>
> On Wed, Apr 23, 2025 at 13:49 Jon Haddad <j...@rustyrazorblade.com> wrote:
>
> >   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.
>
> Jon
>
>
>
> On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever <m...@apache.org> wrote:
>
>    .
>
>
> 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.
>
>
>
>

Reply via email to