Issue #19614 has been updated by austin (Austin Ziegler). 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. ---------------------------------------- Bug #19614: Adopt Semantic Versioning https://bugs.ruby-lang.org/issues/19614#change-102879 * Author: fulldecent (William Entriken) * Status: Rejected * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby was created in 1995. That's back when the UNIX timestamp was only 9 digits, before Nintendo 64, and before most people on Earth today were born. Since then, basically everybody else in the software industry has adopted Semantic Versioning. **Now it is time for Ruby to make this momentous change.** Not "almost SemVer". Not "sometimes SemVer". Actually "SemVer". This means: 1. Update the major version number (the FIRST part of the version string) with EVERY backwards incompatible change. 2. Follow every other rule published at https://semver.org/ 3. Tell everybody we are following SemVer. This issue is to promote the cause for SemVer and to change Ruby's release process to enter the 21st century. -- https://bugs.ruby-lang.org/