Bug #19614: Adopt Semantic Versioning

• Status: Rejected
• Assignee: -
• Target version: -
• Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN

[fulldecent (William Entriken)]

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.

[austin (Austin Ziegler)]

This has been discussed and resolved before. See 15456#2 for a note from one of the release maintainers specifically saying that Ruby is mostly a rolling release.

There are flaws with Semantic Versioning as well, see 15456#5. I also do not use full Semantic Versioning for any of my gems because it’s a deeply flawed system.

The SemVer-ish decision was made in #8835 and adopted with 2.1.0.

I do not think that this is going to change.

[fulldecent (William Entriken)]

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.

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.

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.

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.

[naruse (Yui NARUSE)]

• Status changed from Open to Rejected

We don't use Semantic Versioning.

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

[sawa (Tsuyoshi Sawada)]

Ruby was created in 1995. That's [...] before most people on Earth today were born.

An issue including age harassment and hostility like this should be banned. It should have been immediately closed/deleted without any discussion whatsoever.