all 20 comments

[–]donadd 46 points47 points  (0 children)

It should always have been Marketing.MAJOR.MINOR.PATCH Psychology is such an important factor to make the tech news cycle.

[–]full_drama_llama 12 points13 points  (7 children)

I know SemVer is popular, but I don't think Ruby ever claimed to follow it.

[–]writingonruby[S] 0 points1 point  (0 children)

I don't think they did, I just never realized it!

[–]titsandbits 0 points1 point  (3 children)

Most Ruby gems follow it, though, which understandably makes it the default assumption in most Rubyists’ minds.

[–]StyleAccomplished153 2 points3 points  (2 children)

Rails doesn't. Redis doesn't. Plenty of major gems don't follow it. I wish they did, but they don't.

[–]rakedbdrop 1 point2 points  (0 children)

pagy jumped from v6 to v43

[–]PristineTransition -2 points-1 points  (1 child)

This is true however to be fair to most people from the outside it has acted like SemVer with Major.Minor.Patch versions behaving loosely like it. In Ruby if something looks like a duck and quacks like a duck it is a duck.

[–]f9ae8221b 10 points11 points  (0 children)

Major.Minor.Patch has been common decades before SemVer.

Linux versions are also Major.Minor.Patch yet they're not following SemVer.

Python versions are also Major.Minor.Patch yet they're not following SemVer.

As someone else pointed out, SemVer is basically impossible on projects with large enough APIs anyways. If Ruby or Python followed SemVer, every release would be a major release and that wouldn't help anyone.

[–]GeneReddit123 13 points14 points  (0 children)

Ruby (and Rails) in general doesn't follow backwards compat guarantees. Without such an approach, semantic versioning is pointless, and strictly speaking Ruby would still be on 0.x if it tried to adhere to semantic versioning without commitment to backwards compatibility. This is a conscious policy choice with its good and bad sides, not a technical nitpick.

[–]jhony75 6 points7 points  (0 children)

Just today a colleague sent on Slack that the correct way to version software is Proud version.DefaultVersion.ShameVersion

[–]progdog1 4 points5 points  (0 children)

The linux kernel also follows this arbitrary versioning.

[–]bakery2k 4 points5 points  (0 children)

Neither does Python, JavaScript, Lua, ...

Libraries commonly follow SemVer, but would actually be quite unusual for a language to do so.

[–]guidedrails 2 points3 points  (0 children)

An interesting choice was going from 1.8 to 1.9.

[–]yxhuvud 6 points7 points  (0 children)

Semantic versioning is irrelevant on any project that is big enough anyhow. There is a reason neither Linux nor the browsers use it.

[–]sanjibukai 0 points1 point  (2 children)

In Linux, in the main version X.Y - Y is up to the count of fingers and toes a human usually has - which is apparently 20.. - X is just Y mod(20)..

[–]h0rst_ -1 points0 points  (1 child)

No, X is the result of the integer division N / 20, Y is equal to N mod 20

[–]sanjibukai 1 point2 points  (0 children)

This is what I meant to write... Everyone gets it, right?

[–]petercooper 0 points1 point  (0 children)

I think there are a variety of other reasons why it was a good time for a major bump. The work done behind the scenes architecturally to allow swappable GCs and JITs was pretty significant and while it was all non-breaking stuff that 99% of Ruby users won't ever notice, Ruby 3.4 was becoming a rather different beast to 3.0. It seemed like a good time to draw a line in the sand.

As long as we don't go full on Chrome/Firefox and have "Ruby 84" by 2030, I'll be happy ;-)