It's been 7 days and I think we have a clear consensus w/some good follow up action items.
Vote results: • Binding: 16 in favor (roll call: 21) • Non-binding: 5 in favor • Dissent: none Follow ups: • Enshrine this agreed upon procedural text in our wiki w/link to discussion and vote threads • Document in wiki and reference ML where we reached consensus on API addition or removal requiring consensus (and any other details or procedures we reached on that thread) • Open a follow up [DISCUSS] thread on dev ML re: how we deal with JDK support, evolution, and deprecation (referencing any previous discussion on that topic) As always, thanks everyone for your input, thoughts, and feedback to help refine our processes. ~Josh On Thu, Apr 24, 2025, at 12:03 AM, Joseph Lynch 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 > > > 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. >>>>>>>> >>
