It's obviously still in progress, but CASSANDRA-16052 <https://issues.apache.org/jira/browse/CASSANDRA-16052> may introduce some breaking changes to the 2i API.
On Mon, Sep 26, 2022 at 12:45 PM Josh McKenzie <jmcken...@apache.org> wrote: > qualifies to me as “this release is not backwards compatible with 4.1”. > > I'm +1 on considering dropping a specific JDK's support as being a > non-backwards compatible change. > > On Mon, Sep 26, 2022, at 1:34 PM, Jeremiah D Jordan wrote: > > If we drop Java 8 support then I would think we need to go to 5.0. That > definitely qualifies to me as “this release is not backwards compatible > with 4.1”. > > -Jeremiah > > On Sep 26, 2022, at 12:12 PM, Aleksey Yeshchenko <alek...@apple.com> > wrote: > > Don’t have an opinion on designating 4.2 as 5.0 instead, though it might > be a nice idea for marketing reasons, if enough splashy features make it > into it. > > If or when we go with 5.0 however, we don’t have to drop any compatibility > with older versions just because our SemVer rules technically allow us to. > Extended compatibility is a worthy feature to have and should be kept for > as long as feasible. > > — > AY > > On 26 Sep 2022, at 18:00, Mick Semb Wever <m...@apache.org> wrote: > > > More precisely, do we want to drop anything 4.x deprecated, or do we want > to drop support in trunk for upgrading from 3.x ? And are we ready to > commit now to saying let trunk be 5.0 ? > > Our SemVer versioning rules, being operator rather than user facing, > state that these compatibility concerns are the requirements that warrant a > major version jump. (Because we are otherwise always to be strict with > providing compatibility.) > > A separate question: do we want our major version to jump simply because > we drop support for an older JDK? My opinion is that we shouldn't, as this > would churn our version numbers and leave us less in control of > (minimising) the upgrade paths we force our users to go through. And that's > not to say new JDKs won't force other changes that themselves justify the > jump. > > > > >