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 <m...@apache.org> 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. >> >> >>>>
