Maybe this is not the right place to bring up practicalities, but the more upgrade paths we support the more complexity we take on. The ongoing issues mentioned in CASSANDRA-20118 are illustrative and the introduction of Storage Compatibility Mode adds further dimensions and operational complexity to any upgrade. At the very least, SCM needs decoupling from messaging versions as in its current form it prevents new versions from introducing any messaging format changes, regardless of any impact on storage formats.
* Should 5.1/6.0 continue to support CASSANDRA_4 SCM? (if we are going to support upgrades from 4.x then it has to). * Do we have any plans for CASSANDRA_5 compatibility mode when upgrading to 5.1/6.0? * If we want to continue to allow upgrades to jump multiple versions, do we allow any intermediate SCM setting? (i.e. go from 4.x to 6.x with SCM set to 5?) Sorry for going off topic re: the actual number we give to the next release, I really don't feel strongly about 5.1 vs 6.0. Thanks, Sam > On 11 Dec 2024, at 11:02, Rahul Singh (ANANT) <rahul.si...@anant.us> wrote: > > +1 for calling it 6, even if just to bring up to people on 2.x,3.x that they > are on "ancient" code. > > Sent via Superhuman iOS > > > On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko <alek...@apple.com> wrote: > We don’t really practice canonic sermver, we never really have, and it’s > impossible to properly follow anyway. > > Should be perfectly fine to bump to 6.0, so long as we don’t take the bump as > a license to break compatibility in a way that we wouldn’t have for 5.1. > > >> On 11 Dec 2024, at 00:11, Jon Haddad <j...@rustyrazorblade.com> wrote: >> >> > A lot has already been cleaned in 4.0 that makes 3.x to 5.x now >> > non-functioning. And the cleaner code certainly helps navigate the code >> > base quicker. >> >> Sure - I was using that as an example, looking back in hindsight. Like, if >> today people could go from 2.1 -> 5.0 it would be cool. Applying it to the >> future, if someone could go from 4.1 to 7.0, that would be nice. >> >> I have no clue what that means for maintenance. If it slowed development >> time down, it becomes less useful. >> >> Jon >> >> >> >> >> >> >> >> On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever <m...@apache.org> wrote: >> >> >> I know a few teams on 2.2 that would *love* to be able to jump right to 5.0. >> Once you fall far enough behind, upgrading to another version that's >> already deprecated becomes paralyzing. I don't expect 2.2 compatibility >> btw, just using it as an example. >> >> If it can be done, it would make a lot of folks very happy. >> >> If we could pull that off that would be great. I would like to see it >> happen first. >> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now >> non-functioning. And the cleaner code certainly helps navigate the code >> base quicker. >> >> (It was agreed to keep sstable format compatible indefinitely, but that's >> about offline upgrading. And even the bugs that exist around frozen >> tuples/udts in the ma-md versions, I would suggest there's value in raising >> the minimum compatibility to `me`. This is an example that these breakages >> still do happen, hopefully less over time, and _drawing a line in the sand_ >> is a legit tactic to deal with them.) >> >> >> @Mick, you made me laugh, with your unique ability to agree disagreeably. >> You might not care about marketing, but people pay more attention to major >> version upgrades and "minor" ones. Even though this can be in no way be >> considered a minor change. It doesn't matter what people "should" do. >> Major version bump is a signal to end users that this is a BIG DEAL. >> >> >> Yup! A healthy community needs to be one where it's safe to present diverse >> and/or unpopular points of view, without fear or concern of the initial >> phase of discussion stagnating :-) >> Bikeshedding aside, my opinion is that the signal/feedback to the operator >> about what they need to do is of more concrete value than the new features >> list to the user. >> >> Aside, it is unfortunate that we associate minor semver version numbers as >> "minor". They are, after all, still referred to as major releases. It is >> just separate terminology between releases and semver that we are tripping >> ourselves up over it, and our emphasis on "the number". Ideally (imho) it >> would be wonderful to keep semver private to us and operators, having some >> other mechanism to signal user-facing/marketing, like we do with sstable >> formats – but that's still always going to leak out in some way. >> >
