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.
>
>
>
>
>

Reply via email to