We're at quorum so vote passes! Binding: 14 +1, no -1 Non-binding: 3 +1 And that means I won't feel guilty for engaging in more discussion on a [VOTE] thread. :D > • potential necessity to update 3rd party dependencies in GA branches to > support a newer JDK > • deprecating of JDK features we use: Great points Dmitry.
The addition of runtime support for new JDK's on older GA branches feels like the minimal possible introduction of instability into those older branches to gain the "lowest risk" benefits (i.e. JDK ecosystem runtime changes) while preserving the ability to do live upgrades from a GA release to newest GA. The option to always stay on the older JDK's for your runtime constrains exposure to instability to just dependency bumps + code-changes to support new JDK's, which feels acceptable to me in infra software (we bump deps for CVE's already, make code-changes for correctness, etc). The alternative calibration is our status quo where prioritization of "crystallizing old releases in amber" comes at the cost of *very slow adoption* of new JDK / infra functionality in our new releases. If we released yearly, the status quo leaves us at 3 years behind on adoption of new LTS JDK's. Since we don't hit that yearly mark historically, we're closer to 5-7 years behind on LTS adoption (or longer if you look at our marriage to JDK8...) On Wed, Jun 18, 2025, at 6:22 PM, Patrick McFadin wrote: > +1 > > On Wed, Jun 18, 2025 at 3:17 PM Dmitry Konstantinov <netud...@gmail.com> > wrote: >> +1 (nb) >> >> There are the following pain points (mentioned in the discussion thread as >> well) related to this option but other options look even worse :-), so I >> think it is a fair cost: >> • potential necessity to update 3rd party dependencies in GA branches to >> support a newer JDK >> • deprecating of JDK features we use: the nearest one which I see is Unsafe >> methods removal (probably since JDK26) which will force us to switch to FFM >> API (which one is GA only since JDK 22, so it means to support older JDK >> versions we have to introduce some kind of conditional logic around it). >> >> >> >> >> On Wed, 18 Jun 2025 at 22:37, Jordan West <jw...@apache.org> wrote: >>> +1 >>> >>> On Wed, Jun 18, 2025 at 8:28 AM C. Scott Andreas <sc...@paradoxica.net> >>> wrote: >>>> +1 >>>> >>>>> On Jun 18, 2025, at 11:08 AM, Aleksey Yeshchenko <alek...@apple.com> >>>>> wrote: >>>>> +1 >>>>> >>>>>> On 18 Jun 2025, at 14:24, Josh McKenzie <jmcken...@apache.org> wrote: >>>>>> >>>>>> We're at 10 binding +1. Need 3 more to move this across the line. >>>>>> >>>>>> On Tue, Jun 17, 2025, at 6:58 PM, Joseph Lynch wrote: >>>>>>> +1 >>>>>>> >>>>>>> On Tue, Jun 17, 2025 at 1:47 PM David Capwell <dcapw...@apple.com> >>>>>>> wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>>> On Jun 17, 2025, at 3:44 AM, Štefan Miklošovič >>>>>>>>> <smikloso...@apache.org> wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> On Fri, Jun 13, 2025 at 1:58 PM Josh McKenzie <jmcken...@apache.org> >>>>>>>>> wrote: >>>>>>>>>> __ >>>>>>>>>> [DISCUSS] thread: >>>>>>>>>> https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft >>>>>>>>>> >>>>>>>>>> Text to vote on: >>>>>>>>>> -------------------------------------------------------------------------------------- >>>>>>>>>> *[New LTS JDK Adoption]* >>>>>>>>>> • When a new JDK goes LTS, we prioritize: >>>>>>>>>> • Moving trunk to build, run, pass CI, and support language level >>>>>>>>>> of that JDK, dropping others >>>>>>>>>> • Adding support to *run* on that JDK to all supported GA >>>>>>>>>> releases, passing all CI using that JDK >>>>>>>>>> • These 2 operations must merge atomically. This allows us to >>>>>>>>>> preserve the contract of allowing like-to-like JDK's for a live C* >>>>>>>>>> upgrade >>>>>>>>>> *[Build, run, language level, Pre Commit CI, EOL]* >>>>>>>>>> • trunk builds, runs, has CI on, and supports the language level of >>>>>>>>>> 1 JDK at any given time (ideally latest LTS JDK) >>>>>>>>>> • Supported non-trunk GA branches: >>>>>>>>>> • build, run, pass CI, and support the language level of *the >>>>>>>>>> oldest JDK they are certified for* >>>>>>>>>> • Are supported to *run* on all LTS JDK's between their oldest >>>>>>>>>> supported and newest LTS supported by trunk >>>>>>>>>> • In the very rare case a feature would have to be removed due to >>>>>>>>>> JDK change (think UDF's scripting engine), we instead keep the >>>>>>>>>> maximum allowable JDK for that feature supported on trunk and >>>>>>>>>> subsequent releases. The feature is flagged for >>>>>>>>>> deprecate-then-remove or re-implementation based on dev ML >>>>>>>>>> discussion. If removed, we drop the required older JDK across all >>>>>>>>>> branches when the feature is removed. Supporting new LTS JDK's is >>>>>>>>>> considered higher priority than supporting features that JDK's are >>>>>>>>>> no longer compatible with, pending debate on the dev ML. >>>>>>>>>> • Dropping JDK support happens naturally as old releases go EOL. >>>>>>>>>> *[Post Commit JDK validation CI]* >>>>>>>>>> • Periodically we will run all CI pipelines for all *runtime* >>>>>>>>>> supported JDK's for that branch (cadence TBD) >>>>>>>>>> • We will add basic perf testing across all GA branches + their >>>>>>>>>> supported runtime JDK's with reference workloads from >>>>>>>>>> easy-cass-stress for a simple performance-based smoke test >>>>>>>>>> -------------------------------------------------------------------------------------- >>>>>>>>>> Vote structure: >>>>>>>>>> • Roll call >>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance> >>>>>>>>>> is 25. >>>>>>>>>> • Quorum: 13 (min required votes to qualify results) >>>>>>>>>> • Super-majority of participating votes in favor required to pass >>>>>>>>>> (9 in favor at 13 min votes, etc) >>>>>>>>>> Will leave the vote open for a week. >>>>>>>>>> >>>>>> >>>>> >> >> >> -- >> Dmitry Konstantinov
