Just a small distinction: semantic versioning does nothing to prevent you from breaking, it just take the high road by calling it a different version number.
My big issue with semantic versioning, which I endorse on the whole, is that it says it's okay to change public interfaces between major versions. That's fine if your environment allows you to activate two different versions of a library, but most don't. In this case, it means even if RubyGems was called 2.0, you'd have the same technical problems if you have libs with dependencies on RubyGems 1.x and other libs with dependencies on RubyGems 2.x. Modules really should be used to namespace interfaces across major versions.
The whole point of versioning, however, is to designate how big changes are between versions. There's a world of difference between 0.2.1 to 0.2.2 versus 0.2.1 and 0.3.0. That's what I'm mostly concerned about- patch versions should be a relatively low-stress change between versions. Changing that minor or major number to designate something large is coming is important.
I agree that it doesn't necessarily mean that you won't have to rework your local code, but particularly with projects like RubyGems (which are more end-user than code integration points), it's more important to know whether or not upgrading will break your entire process.
It's important as a communication tool. But you'd still be in a world of hurt because that logical distinction doesn't affect execution semantics. The problem is exacerbated once transitive dependencies enter the picture.
As a concrete example, the redis-rb gem went to 2.0 and completely broke API compatibility. They did everything right by the semantic versioning book. I used about 10 libraries built atop redis-rb, but never used redis-rb directly. About half the libs updated and required the use of redis-rb 2.0, the other half did not. Moreover, the gem dropped protocol support for the old redis-server, too, so it forced a redis-server upgrade.
This was an absolute mess to work out because updating 10 libs at once is basically insane. And the whole thing could have been avoided if modules were used to namespace, allowing activation of both sets of classes.
But, anyway, this isn't to say semantic versioning has no value. It's just not a solution to a library that keeps changing its public API either.
RubyGems doesn't follow SemVer, it follows Ruby's versioning system. :(
(offtopic) Also, I too got bit by the redis-rb changes. They also broke apis from 2.1 => 2.2 as well. SemVer isn't hard, I don't understand why people can't follow it.
Hm? RubyGems doesn't enforce any particular versioning system, packagers to free to use semantic versioning. Or are you talking about RubyGems itself and not RubyGems packages?
My big issue with semantic versioning, which I endorse on the whole, is that it says it's okay to change public interfaces between major versions. That's fine if your environment allows you to activate two different versions of a library, but most don't. In this case, it means even if RubyGems was called 2.0, you'd have the same technical problems if you have libs with dependencies on RubyGems 1.x and other libs with dependencies on RubyGems 2.x. Modules really should be used to namespace interfaces across major versions.