fulldecent (William Entriken) wrote in #note-2:
I understand that this was discussed and decided in 2013.
That decision might have made sense in 2013 for the Ruby community.
But that was forever ago.
It was yesterday, in Ruby terms, and it still makes sense for the Ruby community. As long as I have to support Ruby 2.7 (and note that some of my gems are still nominally supporting Ruby 1.8 because I don’t feel like making the semver-ish change that I would need to do in order to jettison that version), then semantic versioning provides me exactly zero value when considering Ruby.
Maybe back then there was some doubt that everybody would be using SemVer. Today there is no remaining doubt—basically the whole world uses SemVer, it is superior, and basically everybody is expecting everybody else to use it.
That was not, to the best of my knowledge, the basis for the choice of the modified semantic versioning used by Ruby.
If you want a superior versioning approach, use CalVer. Semantic versioning is mostly a promise that is not well kept and has introduced nonsensical things like conventional commits (using up several characters of the mere 52 available on a well-formed git commit message is utter bollocks).
I only use modified SemVer. My modified SemVer choices are different than those used by Ruby, but I will never use the SemVer "standard" as written—it’s mostly nonsense. I have also reverted functionality added in a v1.0 in a v1.1 (it was 15 years ago, but it was the Right Choice). Versioning is always a marketing choice and anyone pretending otherwise is selling NFTs as water.
As far as the incorrect notion that semver is used by everyone…I point you to Typescript 5.0. The number is pure marketing and just happens to be the next number after Typescript 4.9. They are using an approach very similar to the approach of Ruby.
By not using SemVer, Ruby is burying its major backwards-breaking changes in smaller version numbers. That is what makes Ruby so painful... backwards-compatible breaking changes.
The only real incompatibility of which I am aware from 2.7 to 3.2 is the removal of File#exists?
in 3.2, which had been deprecated for a very long time. I maintain widely used gems which have seen almost zero change because of the language since Ruby 1.9.
SemVer requires projects to be more thoughtful, explicit, and accountable about these changes. So now, as always, is a great time to start doing that.
SemVer is a flawed concept which should only be used in a modified form. Accepting a poorly-written and considered standard as gospel is a mistake.