You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Mick Semb Wever <mc...@apache.org> on 2022/09/26 17:00:38 UTC
Shall 4.2 become 5.0 ?
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.
Re: Shall 4.2 become 5.0 ?
Posted by Sam Tunnicliffe <sa...@beobal.com>.
> do we want to drop support in trunk for upgrading from 3.x ?
This is a bit premature as it hasn't even gone to a vote yet, but if accepted, CEP-21 might make this something we want to do.
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21:+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-MigrationPlan
> On 26 Sep 2022, at 18:00, Mick Semb Wever <mc...@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.
>
>
>
Re: Shall 4.2 become 5.0 ?
Posted by Patrick McFadin <pm...@gmail.com>.
Removing JDK 8 is worth it alone. CEP-21 is going to be the real break
though, and with CEP-15 tied to it, I can't see another path.
Patrick
On Mon, Sep 26, 2022 at 1:46 PM Caleb Rackliffe <ca...@gmail.com>
wrote:
> Mick,
>
> Ignore me. I misread your original post.
>
>
>
> On Mon, Sep 26, 2022 at 2:01 PM Ekaterina Dimitrova <e....@gmail.com>
> wrote:
>
>> We agreed long ago to drop the JavaScript UDFs, they were already
>> deprecated in CASSANDRA-17280
>> That was decided around Nashorn and JDK17 and there is ticket
>> CASSANDRA-17281 to cover that effort.
>>
>> On Mon, 26 Sep 2022 at 14:05, Mick Semb Wever <mc...@apache.org> wrote:
>>
>>>
>>> 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.
>>>>
>>>
>>>
>>> Can you elaborate Caleb? To my understanding, we do not want (and this
>>> thread is not about) permitting breaking changes from one version to the
>>> next. Are there deprecated 2i APIs in 4.x that you will need removed for
>>> 16052 ?
>>>
>>>
Re: Shall 4.2 become 5.0 ?
Posted by Caleb Rackliffe <ca...@gmail.com>.
Mick,
Ignore me. I misread your original post.
On Mon, Sep 26, 2022 at 2:01 PM Ekaterina Dimitrova <e....@gmail.com>
wrote:
> We agreed long ago to drop the JavaScript UDFs, they were already
> deprecated in CASSANDRA-17280
> That was decided around Nashorn and JDK17 and there is ticket
> CASSANDRA-17281 to cover that effort.
>
> On Mon, 26 Sep 2022 at 14:05, Mick Semb Wever <mc...@apache.org> wrote:
>
>>
>> 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.
>>>
>>
>>
>> Can you elaborate Caleb? To my understanding, we do not want (and this
>> thread is not about) permitting breaking changes from one version to the
>> next. Are there deprecated 2i APIs in 4.x that you will need removed for
>> 16052 ?
>>
>>
Re: Shall 4.2 become 5.0 ?
Posted by Ekaterina Dimitrova <e....@gmail.com>.
We agreed long ago to drop the JavaScript UDFs, they were already
deprecated in CASSANDRA-17280
That was decided around Nashorn and JDK17 and there is ticket
CASSANDRA-17281 to cover that effort.
On Mon, 26 Sep 2022 at 14:05, Mick Semb Wever <mc...@apache.org> wrote:
>
> 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.
>>
>
>
> Can you elaborate Caleb? To my understanding, we do not want (and this
> thread is not about) permitting breaking changes from one version to the
> next. Are there deprecated 2i APIs in 4.x that you will need removed for
> 16052 ?
>
>
Re: Shall 4.2 become 5.0 ?
Posted by Mick Semb Wever <mc...@apache.org>.
> 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.
>
Can you elaborate Caleb? To my understanding, we do not want (and this
thread is not about) permitting breaking changes from one version to the
next. Are there deprecated 2i APIs in 4.x that you will need removed for
16052 ?
Re: Shall 4.2 become 5.0 ?
Posted by Caleb Rackliffe <ca...@gmail.com>.
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 <jm...@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 <al...@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 <mc...@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.
>
>
>
>
>
Re: Shall 4.2 become 5.0 ?
Posted by Josh McKenzie <jm...@apache.org>.
> 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 <al...@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 <mc...@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.
>>>
>>>
>>>
Re: Shall 4.2 become 5.0 ?
Posted by Jeremiah D Jordan <je...@gmail.com>.
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 <al...@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 <mck@apache.org <ma...@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.
>>
>>
>>
>
Re: Shall 4.2 become 5.0 ?
Posted by Mick Semb Wever <mc...@apache.org>.
>
>
> So the TL;DR here is that you (Mick) now also agree we should move the
>> version to 5.0? I haven’t seen any other arguments for staying on 4.2, so
>> should we just move the version number to 5.0 now? Do we want to have a
>> VOTE thread for it? Or should we just do it?
>>
>
> I was never against 5.0, and I see no need for a vote – no objection in
> this thread for 5.0.
>
Moved to CASSANDRA-17973
Re: Shall 4.2 become 5.0 ?
Posted by Mick Semb Wever <mc...@apache.org>.
So the TL;DR here is that you (Mick) now also agree we should move the
> version to 5.0? I haven’t seen any other arguments for staying on 4.2, so
> should we just move the version number to 5.0 now? Do we want to have a
> VOTE thread for it? Or should we just do it?
>
I was never against 5.0, and I see no need for a vote – no objection in
this thread for 5.0. Folk have provided clear rationale to why it should be
5.0, totally appreciated.
The additional discussion is only an attempt to move us forward on (and
simplify) why and what distinction we have between majors and minors. (Or
whether we want the distinction at all.)
Re: Shall 4.2 become 5.0 ?
Posted by Jeremiah D Jordan <je...@gmail.com>.
So the TL;DR here is that you (Mick) now also agree we should move the version to 5.0? I haven’t seen any other arguments for staying on 4.2, so should we just move the version number to 5.0 now? Do we want to have a VOTE thread for it? Or should we just do it?
-Jeremiah
> On Oct 16, 2022, at 9:19 PM, Mick Semb Wever <mc...@apache.org> wrote:
>
>
> To summarise, we need to make 4.2 into 5.0, as
> - we need to remove (the already deprecated) JavaScript UDFs to add JDK 17,
> - dropping support for JDK8 would make it impossible to upgrade from 3.x (see explanation below),
> - CEP-21 (once accepted) will be easier without having to support 3.x compatibility. It is also my understanding that CEP-15 requires CEP-21.
>
>
>
> Otherwise, inline replies on the topics of why operator centric major version delimitation, the amount of resources required to provide extended compatibility, and why dropping support for one JDK is not (in itself) a compatibility breakage.
>
>
> 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.
>
>
> Aleksey, I am not keen on the notion of versioning by marketing. Our versioning can be valuable and intuitive feedback to operators, making their upgrades simpler and safer, if we can keep it consistent.
>
> If marketing cannot market Accord and Transaction Cluster Metadata, I think we have bigger problems on our hands.
>
> Marketing can be seen as external to engineering, and should not be imposed by our semver notion of major versions, they should be entirely free to use whatever adjectives they like against each annual release.
>
> A strong dose of personal opinion here, but I really think we're over-playing the leading digit of our version numbers against a user base that's far more diverse and intelligent than we're giving them credit for. My own anecdote is that I would struggle to tell you the current version number of many other technologies. And I experience regularly that many users don't immediately know the version they are running when asked. We should embrace such cluelessness – they have more important things to know and to remember, and it's easy enough to figure it out when needed.
>
> One of the common challenges users come to us (C* consulting) is to deal with upgrades. Every little bit of simplification they can get from us to understand and prepare for the impacts of non-patch upgrades goes a long way. Many have been badly burnt by upgrades, it's not as easy as we'd like to think it is.
>
> This touches on why I don't believe major versions should be tied to dropping JDKs: there's a lot more going on underneath C* than just the JDK. Users are requested to keep their systems up to date, and this involves the kernel, dist, native libraries, python, and drivers. We need to be encouraging users to be keeping their systems up to date between upgrades, not when performing upgrades.
>
> The more we can do to de-risk major upgrades the better.
>
>
> 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.
>
>
> I totally agree that extended compatibility is a worthy feature. But… extended compatibility has overhead (on more than just code). Restricting upgrade paths to reduce testing costs seems an obvious example. The problem I see is that once we make that decision to increment the major we then slowly but surely stop caring for compatibility over non-adjacent majors. How do we minimise overload on our limited community engineering resources, while ensuring extended compatibility ?
>
>
> 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, I agree and disagree here, though you have definitely changed my thinking around this :-)
>
> I'm in favour of separating JDK support from any direct notion of C* compatibility, for the purpose of de-risking major upgrades via promoting the upgrade of runtime dependencies separately. We can do this if we also say, throughout any major version there must be one JDK consistently supported.
>
> While I disagree that dropping a single JDK (in itself) implies compatibility is broken; we must not break compatibility from one major to the next; dropping all supported JDKs would indeed break compatibility. For example, with 3.0 and 3.11 only supporting JDK8, this means that all 4.x versions must also support JDK8, and any new version that no longer has any JDKs in common with 3.x must become 5.x
>
> So I would totally agree with your statement, if it were slightly tweaked as:
> If we drop Java 8 support then I would think we need to go to 5.0. That qualifies as “this release is not backwards compatible with 3.0 or 3.11”.
>
> This will also give us more room to move, on the assumption we will want a major roughly every three years to avoid users upgrading from unmaintained versions, and we don't want a major every year as that would burn operators.
>
> If we can get some alignment on this I will put together a PR to better document these things, we need a page for our JDK support matrix, and a page on upgrade requirements.
>
Re: Shall 4.2 become 5.0 ?
Posted by Mick Semb Wever <mc...@apache.org>.
To summarise, we need to make 4.2 into 5.0, as
- we need to remove (the already deprecated) JavaScript UDFs to add JDK 17,
- dropping support for JDK8 would make it impossible to upgrade from 3.x
(see explanation below),
- CEP-21 (once accepted) will be easier without having to support 3.x
compatibility. It is also my understanding that CEP-15 requires CEP-21.
Otherwise, inline replies on the topics of why operator centric major
version delimitation, the amount of resources required to provide extended
compatibility, and why dropping support for one JDK is not (in itself) a
compatibility breakage.
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.
>
Aleksey, I am not keen on the notion of versioning by marketing. Our
versioning can be valuable and intuitive feedback to operators, making
their upgrades simpler and safer, if we can keep it consistent.
If marketing cannot market Accord and Transaction Cluster Metadata, I think
we have bigger problems on our hands.
Marketing can be seen as external to engineering, and should not be imposed
by our semver notion of major versions, they should be entirely free to use
whatever adjectives they like against each annual release.
A strong dose of personal opinion here, but I really think we're
over-playing the leading digit of our version numbers against a user base
that's far more diverse and intelligent than we're giving them credit for.
My own anecdote is that I would struggle to tell you the current version
number of many other technologies. And I experience regularly that many
users don't immediately know the version they are running when asked. We
should embrace such cluelessness – they have more important things to know
and to remember, and it's easy enough to figure it out when needed.
One of the common challenges users come to us (C* consulting) is to deal
with upgrades. Every little bit of simplification they can get from us to
understand and prepare for the impacts of non-patch upgrades goes a long
way. Many have been badly burnt by upgrades, it's not as easy as we'd like
to think it is.
This touches on why I don't believe major versions should be tied to
dropping JDKs: there's a lot more going on underneath C* than just the JDK.
Users are requested to keep their systems up to date, and this involves the
kernel, dist, native libraries, python, and drivers. We need to be
encouraging users to be keeping their systems up to date between upgrades,
not when performing upgrades.
The more we can do to de-risk major upgrades the better.
> 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.
>
I totally agree that extended compatibility is a worthy feature. But…
extended compatibility has overhead (on more than just code). Restricting
upgrade paths to reduce testing costs seems an obvious example. The problem
I see is that once we make that decision to increment the major we then
slowly but surely stop caring for compatibility over non-adjacent majors.
How do we minimise overload on our limited community engineering resources,
while ensuring extended compatibility ?
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, I agree and disagree here, though you have definitely changed my
thinking around this :-)
I'm in favour of separating JDK support from any direct notion of C*
compatibility, for the purpose of de-risking major upgrades via promoting
the upgrade of runtime dependencies separately. We can do this if we also
say, throughout any major version there must be one JDK consistently
supported.
While I disagree that dropping a single JDK (in itself) implies
compatibility is broken; we must not break compatibility from one major to
the next; dropping all supported JDKs would indeed break compatibility. For
example, with 3.0 and 3.11 only supporting JDK8, this means that all 4.x
versions must also support JDK8, and any new version that no longer has any
JDKs in common with 3.x must become 5.x
So I would totally agree with your statement, if it were slightly tweaked
as:
If we drop Java 8 support then I would think we need to go to 5.0. That
qualifies as “this release is not backwards compatible with 3.0 or 3.11”.
This will also give us more room to move, on the assumption we will want
a major roughly every three years to avoid users upgrading from
unmaintained versions, and we don't want a major every year as that would
burn operators.
If we can get some alignment on this I will put together a PR to better
document these things, we need a page for our JDK support matrix, and a
page on upgrade requirements.
Re: Shall 4.2 become 5.0 ?
Posted by Aleksey Yeshchenko <al...@apple.com>.
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 <mc...@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.
>
>
>