[TokenDiversity]

Exactly. This is just a bad use of "Semver". It's still a "version" right? 2018 vs 2015?

If they're so concerned, maybe add another figure to the left.

Current version could be 1.1.42.0 and the "eopch" could be 1.2.3.9? Maybe breaking could be 2.0.0.0? I'd much rather see a unification around semver then create a different identifier called epoch only to stay radically faithful to a definition of semver

[OskarS]

I feel like this is only a problem if you stick religiously to semver. This problem more or less boils down to:

1) We want to indicate that a major update to the language has happened, so we want to bump the major version number

2) We can't bump the major version number, because we're not making breaking changes, so our semver dogma forbids it.

3) Lets add a completely new version number that's even MORE important than the major version number and call it "epoch", and lets not have that follow any semver semantics!

You have a major version number already. Just bump that. Don't make up a new one. There's no federal law saying you have to follow every rule of semver, you can just make the decision to release Rust 2.0.

Don't get me wrong, i think semver is a great policy for version numbering. But you have to recognize when it's causing more problems than it solves.

[Ericson2314]

They are indeed making a breaking change in that some new code will not be valid previously, and some old code will not be valid after.

They are totally correct that since everything interfaces with each other, this is not a problem in practice. But they are worried about the stupid knee-jerk negative publicity that well occur—I don't dispute that.

But this is extra complexity to pander to idiots.

[Ericson2314]

Ah yes, a leading super major version to denote linking compatability would be an excellent idea!