+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 <https://sprh.mn/?vip=rahul.si...@anant.us> 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. >> >> >
