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