I think there's absolutely nothing wrong with what React did just now -- they have used the system effectively. (The only problem is that they waited this long to do it).
They realized React is _already_ used in production, so it should _already_ be 1.0, and they should be using semver so consumers know when there are breaking changes between versions and when there aren't.
They did exactly the right thing.
The semver doc already says:
> If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
But it is true that this is frequently ignored by people who otherwise think they're doing semver.
I guess _one_ way to deal with that would be to remove "0.x" from semver altogether -- the first version you are allowed to release is 1.0, and it must follow semver rules.
But there are plenty of people who don't use semver at all, that would just increase if you removed the availability of pre-1.0 unstable releases.
I wish everyone used semver, and I wish everyone who said they were using it actually were using it, and I wish everyone using it followed that part about "If it's being used by tons of people in production and/or you are thinking about backwards compat at all, it should already be 1.0" But what can you do.
The semver spec is good already -- I don't agree there's a "fundamental problem" with it in the area you speak of, the problem is people not caring about semver. Changing what's written in the spec won't improve people's behavior in these areas, alas.
For stuff I write, as soon as _I_ am using it in production, it's 1.0. That's pretty straightforward and objective. Sometimes I give it a couple weeks in production myself as a beta/rc before I tag it 1.0, to take the pain of early bugs myself instead of foisting it on others. No more than that.
It's not always that simple, and it may not be totally objective down to the timestamp, but we can think of _many_ cases where people kept an 0.x version number _long_ after it was obvious they shoudln't be -- the authors were using it in production, they knew hundreds or thousands of developers were using it in production, they knew they _were_ thinking of backwards compatibility.
React was my prime example before now.
The problem isn't different judgements on grey areas, the problem is people completely ignoring the intent of the 0.x versioning -- so they can maybe sort of pretend they are doing semver, while not doing it at all.
The first time you realize you can't make an enormous backwards compatible change without telling anyone, or you're a jerk -- is another good milestone.
Who cares if sometimes it could have been somewhat earlier or later. I'm pretty sure if everyone actually tried, it'd work out orders of magnitude better.
If 0.x versions just "weren't allowed", it doesn't _reduce_ the temptation people have _not_ to do semver. 0.x is just a big advertisement "We're NOT using semver... yet, but plan to later. And also this software is super unstable and you really ought not to use it in production" And should be understood thusly.
The problem is when people keep using 0.x, but are clearly _not_ sending that signal. Those people should be shamed.
Well, it's not as if "1.0.0" is meant to offer any logical and universal guarantees for code quality, completeness, etc. compared to, say, 0.7.x -- apart from what semver asks for.
So, as long as it is relatively stable when bumped to 1.0.0, and later releases follow to major/minor rules of semver, it doesn't matter much.
For all of our internal projects we don't push to production til 1.0.0- but because people have different opinions and we live in the world at large we don't have a hard rule of using someone else's code < 1.0.0. We'd just be missing out on too many useful projects.
If it the major version changes for us, the API has probably changed. If it's a minor version bump, the API has DEFINITELY not changed. Rev changes are your typical bug security/performance fixes that are limited in scope.
Who decides all this? If there's any question, just pick the more important signal of the two.
They realized React is _already_ used in production, so it should _already_ be 1.0, and they should be using semver so consumers know when there are breaking changes between versions and when there aren't.
They did exactly the right thing.
The semver doc already says:
> If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
But it is true that this is frequently ignored by people who otherwise think they're doing semver.
I guess _one_ way to deal with that would be to remove "0.x" from semver altogether -- the first version you are allowed to release is 1.0, and it must follow semver rules.
But there are plenty of people who don't use semver at all, that would just increase if you removed the availability of pre-1.0 unstable releases.
I wish everyone used semver, and I wish everyone who said they were using it actually were using it, and I wish everyone using it followed that part about "If it's being used by tons of people in production and/or you are thinking about backwards compat at all, it should already be 1.0" But what can you do.
The semver spec is good already -- I don't agree there's a "fundamental problem" with it in the area you speak of, the problem is people not caring about semver. Changing what's written in the spec won't improve people's behavior in these areas, alas.