Re: Shall 4.2 become 5.0 ?

[Benedict]

So… what’s the problem with bumping our major version because we want to 
communicate a release is “major” rather than has a breaking change - ie that we 
think users should feel incentivised to upgrade to it for whatever reason?

Also, who is talking about never making breaking changes? Breaking changes 
should simply *always* be agreed on list, whatever the version number. The 
default should be no breaking changes, it should be a conscious project-level 
decision to break an element of compatibility.

> On 17 Oct 2022, at 07:56, Mick Semb Wever  wrote:
> 
> 
> 
> 
>> I’m confused: do people pay attention to version numbers or not?
> 
> 
> They pay attention when they go to upgrade. For example when reading NEWS.txt 
> or CHANGES.txt it is a prerequisite you know what version you are on. Many 
> users know, while many others don't because it's so easy to figure out 
> on-the-fly. I don't want to stereotype the user base here.
> 
> As you say we have flexibility with the definition of semver. Since we are an 
> always-on technology we have the opportunity to define what a significant 
> breaking change means to us. I believe we can and should use this opportunity 
> to the benefit of our users, and from experience upgrades are an area where 
> we can (and need to) make things simpler. We can do this by defining it as a) 
> the removal of deprecated APIs, and b) dropping backward compatibility with 
> the previous-previous major.
> 
> If we want to maintain our backward and forward compatibility forever we 
> should do away with major versions altogether.  I'm not in favour of doing 
> that. It creates significant overhead for both engineers and testing 
> resources. And it also misses an incentive to push users to stay up to date.
> 
> 

Re: Looking for reviewers for CircleCI config and doc fix

[Mick Semb Wever]

> I have a minor doc fix for the CircleCI generate.sh script:
>
> https://github.com/apache/cassandra/pull/1902
>
> @adelapena made the change to the script that added the flag, so maybe he
> could take a quick look. On the CircleCI build itself, I have a small PR to
> make the offheap dtests run (they're currently missing):
>
> https://github.com/apache/cassandra/pull/1904
>
> Ekaterina was helping with this but it sounds like she's unavailable until
> next week, so I was wondering if someone else familiar with CircleCI could
> take a look.
>


Thanks for jumping in on these Derek!

It looks like #1902 is already getting tackled via CASSANDRA-17912 …?

I've given #1904 (CASSANDRA-17950) a review.

Note for others, this work along with a number of other tickets falls under
 CASSANDRA-17930 Ensure CircleCI and ASF Jenkins CI are aligned

Re: Shall 4.2 become 5.0 ?

[Alex Petrov]

I'm also a bit confused by the original question: if there's a proposal to 
release 4.2 as 5.0, let's hear out why and just vote for it (list reasons, and 
let everyone express their opinions about why this does or does not warrant the 
version bump). If there are no reasons for us to do, I'm not sure why this is 
important.

The only thing that is related to marking 4.2 as 5.0 in this thread that I can 
list after reading it is JDK support. Are there any other reasons? I did read 
the argument about "incentivising" the upgrade, but major version may in fact 
make people think there has been more changes than there in fact were, making 
them stay on the older version for longer. If this is a way to communicate a 
specific breakage - I think the breakage and ways to communicate it should be 
discussed rather than _just_ version change.

If 5.0 bump is important because of, say, Cassandra Summit, or other marketing 
reasons, I think these are also legitimate, at least if they're used to promote 
Apache Cassandra itself rather than specific vendor's distribution, but it 
doesn't seem like either one of these is the case.

On Mon, Oct 17, 2022, at 9:25 AM, Benedict wrote:
> 
> So… what’s the problem with bumping our major version because we want to 
> communicate a release is “major” rather than has a breaking change - ie that 
> we think users should feel incentivised to upgrade to it for whatever reason?
> 
> Also, who is talking about never making breaking changes? Breaking changes 
> should simply *always* be agreed on list, whatever the version number. The 
> default should be no breaking changes, it should be a conscious project-level 
> decision to break an element of compatibility.
> 
> 
>> On 17 Oct 2022, at 07:56, Mick Semb Wever  wrote:
>> 
>> 
>> 
>>> I’m confused: do people pay attention to version numbers or not?
>> 
>> 
>> They pay attention when they go to upgrade. For example when reading 
>> NEWS.txt or CHANGES.txt it is a prerequisite you know what version you are 
>> on. Many users know, while many others don't because it's so easy to figure 
>> out on-the-fly. I don't want to stereotype the user base here.
>> 
>> As you say we have flexibility with the definition of semver. Since we are 
>> an always-on technology we have the opportunity to define what a significant 
>> breaking change means to us. I believe we can and should use this 
>> opportunity to the benefit of our users, and from experience upgrades are an 
>> area where we can (and need to) make things simpler. We can do this by 
>> defining it as a) the removal of deprecated APIs, and b) dropping backward 
>> compatibility with the previous-previous major.
>> 
>> If we want to maintain our backward and forward compatibility forever we 
>> should do away with major versions altogether.  I'm not in favour of doing 
>> that. It creates significant overhead for both engineers and testing 
>> resources. And it also misses an incentive to push users to stay up to date.
>> 
>> 
 

Re: Shall 4.2 become 5.0 ?

[Mick Semb Wever]

I'm also a bit confused by the original question: if there's a proposal to
> release 4.2 as 5.0, let's hear out why and just vote for it (list reasons,
> and let everyone express their opinions about why this does or does not
> warrant the version bump). If there are no reasons for us to do, I'm not
> sure why this is important.



Consistency. To the benefit of operators.

I totally get from our PoV there's no problem with this being arbitrary.
But from experience witnessing the uncertainty and pain operators go
through, this "decide it each time" is not simplifying it for anyone.

Re: Shall 4.2 become 5.0 ?

[Alex Petrov]

Could you be more explicit? Are you saying we should release 5.0 instead of 4.2 
(which I'm assuming you're advocating for), or are you saying we should release 
4.2?

I still do not understand the question, really. It can't be more important to 
be consistent with versioning than for versions to mean what we want them to 
communicate, but we can do well on both fronts without much additional effort.

On Mon, Oct 17, 2022, at 3:55 PM, Mick Semb Wever wrote:
> 
> 
>> I'm also a bit confused by the original question: if there's a proposal to 
>> release 4.2 as 5.0, let's hear out why and just vote for it (list reasons, 
>> and let everyone express their opinions about why this does or does not 
>> warrant the version bump). If there are no reasons for us to do, I'm not 
>> sure why this is important.
> 
> 
> Consistency. To the benefit of operators.
> 
> I totally get from our PoV there's no problem with this being arbitrary. But 
> from experience witnessing the uncertainty and pain operators go through, 
> this "decide it each time" is not simplifying it for anyone.
>  

Re: Shall 4.2 become 5.0 ?

[Alex Petrov]

Sorry, I did find your email which I have seemingly missed with:

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

At least from my perspective, I would not bump the version just because of UDFs 
and JDK 8. 



On Mon, Oct 17, 2022, at 4:08 PM, Alex Petrov wrote:
> Could you be more explicit? Are you saying we should release 5.0 instead of 
> 4.2 (which I'm assuming you're advocating for), or are you saying we should 
> release 4.2?
> 
> I still do not understand the question, really. It can't be more important to 
> be consistent with versioning than for versions to mean what we want them to 
> communicate, but we can do well on both fronts without much additional effort.
> 
> On Mon, Oct 17, 2022, at 3:55 PM, Mick Semb Wever wrote:
>> 
>> 
>>> I'm also a bit confused by the original question: if there's a proposal to 
>>> release 4.2 as 5.0, let's hear out why and just vote for it (list reasons, 
>>> and let everyone express their opinions about why this does or does not 
>>> warrant the version bump). If there are no reasons for us to do, I'm not 
>>> sure why this is important.
>> 
>> 
>> Consistency. To the benefit of operators.
>> 
>> I totally get from our PoV there's no problem with this being arbitrary. But 
>> from experience witnessing the uncertainty and pain operators go through, 
>> this "decide it each time" is not simplifying it for anyone.
>>  
> 

Re: Shall 4.2 become 5.0 ?

[Benedict]

It’s always arbitrary. We don’t bump major version when we make incompatible 
behavioural changes in bug fixes, for instance. It’s always a judgement: this 
release has important changes you should take a close look at. That’s all it 
means.

Stuff that’s literally arbitrated is always somewhat inconsistent. Versioning 
is arbitrated, by us, and even amongst the semver proponents there’s 
disagreement about what it means to make a breaking change.

The most consistent thing is to drop the distinction entirely, and get rid of 
major/minor.



> On 17 Oct 2022, at 15:09, Alex Petrov  wrote:
> 
> Could you be more explicit? Are you saying we should release 5.0 instead of 
> 4.2 (which I'm assuming you're advocating for), or are you saying we should 
> release 4.2?
> 
> I still do not understand the question, really. It can't be more important to 
> be consistent with versioning than for versions to mean what we want them to 
> communicate, but we can do well on both fronts without much additional effort.
> 
> On Mon, Oct 17, 2022, at 3:55 PM, Mick Semb Wever wrote:
>> 
>> 
>> I'm also a bit confused by the original question: if there's a proposal to 
>> release 4.2 as 5.0, let's hear out why and just vote for it (list reasons, 
>> and let everyone express their opinions about why this does or does not 
>> warrant the version bump). If there are no reasons for us to do, I'm not 
>> sure why this is important.
>> 
>> 
>> Consistency. To the benefit of operators.
>> 
>> I totally get from our PoV there's no problem with this being arbitrary. But 
>> from experience witnessing the uncertainty and pain operators go through, 
>> this "decide it each time" is not simplifying it for anyone.
>>  

Re: Shall 4.2 become 5.0 ?

[Mick Semb Wever]

Sorry, I did find your email which I have seemingly missed with:
>


Thanks :-)



> > 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.
>
> At least from my perspective, I would not bump the version just because of
> UDFs and JDK 8.
>


WRT to JDK 8 that was my original opinion. But the more I thought about
what Jeremiah wrote, the more I realised how uncomfortable (and how I would
struggle to professionally recommend to a customer under paid consulting)
to upgrade a cluster from 3.x JDK 8 nodes to trunk JDK 11 nodes.

We should be encouraging users to update (e.g. upgrade JDK) their systems
between upgrades, and definitely not forcing them to do so at and during
upgrades.

The removal of deprecated stuff (e.g. JavaScript UDFs) is a simplification
and signal to operators, one that also aligns with the "get your system up
to date before the major upgrade".

So again… I'm banging on about taking advantage of creating a distinction
between major/minor that benefits operators. Yes we have things like the
amoeba effect (compatibility isn't obvious after all), but there are
separate tactics to deal with that, though some structure and precedence
does help a lot.

Re: Shall 4.2 become 5.0 ?

[Jeremiah D Jordan]

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

Re: Shall 4.2 become 5.0 ?

[Mick Semb Wever]

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: [Discuss] CASSANDRA-17914: Modernize CQLSH's with argparse for CLI arts

[David Capwell]

As long as this doesn’t break the CLI interface, +1 from me; less dependencies 
are better and valuable work!

> On Sep 29, 2022, at 6:52 AM, Berenguer Blasi  wrote:
> 
> +1
> 
> On 29/9/22 15:42, Derek Chen-Becker wrote:
>> +1 from me. It sounds like a good opportunity!
>> 
>> Cheers,
>> 
>> Derek
>> 
>> On Thu, Sep 29, 2022, 6:26 AM Brad > > wrote:
>> 
>> The Python standard library introduced argparse a decade ago in Python 2.7 
>> to replace optparse as described in PEP-0389 
>>  for command line argument parsing.  
>> Optparse is no longer maintained, and has been deprecated since Python 3.2, 
>> although there are no plans to remove it from the std library.  
>> 
>> As part of modernizing CQLSH, I have proposed in CASSANDRA-17914 that we 
>> upgrade from optparse to argparse.  Argparse is part of the Python standard 
>> library and has been since 2011 so this upgrade involves no new library 
>> dependencies and should be self-contained and transparent.
>> 
>> The primary benefit is removing dependencies on deprecated classes and 
>> components.  Consensus seems to be that argparse has more meaningful help 
>> messages and is more intuitive to use.
>> 
>> 
>> Regards,
>> 
>> Brad Schoening