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