It might not be too bad if done selectively? I agree that would be infeasible for each patch.
How many SCM modes do we have? I worry more about developer burden. It sounds like we have a balancing act with SCM complexity versus upgrade complexity. I think at the very least we should require that whatever you upgrade from should be in max SCM for that version, and the upgraded version should check it is brought up in the equivalent SCM for the new release until upgrade is complete. Hopefully this would prevent SCM from becoming a major extra dimension besides simply minor/major combinations. > On 11 Dec 2024, at 12:43, Marcus Eriksson <marc...@apache.org> wrote: > > Staying slightly off topic - we'd also have to run upgrade tests for all > these upgrade combinations, including different storage compatibility mode > settings, that is going to be very expensive. > > /Marcus > >> On Wed, Dec 11, 2024 at 12:36:02PM GMT, Sam Tunnicliffe wrote: >> 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. >>>> >>> >>
