> 4. Major version zero (0.y.z) is for initial development.
I'd argue that most of the projects we are talking about here are long past initial development.
1. You should have a 0.x.x period for initial development
2. This is the not-stable part of the project lifecycle
3. After 1.x.x. you should be conservative about bumping the major version (not sure if this is from the specification webpage or if this is just the culture around SemVer though)
Point 3 might be what keeps projects on 0ver.
IMO SemVer itself (the culture around it can’t be controlled so that’s outside the domain of discourse) should have just dictated the machine-readable things. Thus points 1 and 2 are fine, but point 3 really discourages large major version integers. I guess some projects can’t realistically follow that. Not because the developers are bad necessarily but simply because breaking changes are part of the domain, more or less.
It seems that only projects that end up reaching a low major version over, say, a decade, fit into the SemVer culture (meaning that people won’t complain about the versioning practice). Maybe some projects simply feel that they get less pushback if they stay on 0ver instead of going for 1.0.0 and then having to go up to 7.0.0 or beyond.
A specification which only consists of three integers (plus the optional “beta”, “rc” appends) is inherently limited. Which is why it should be very limited in scope. SemVer should have just stuck to dictating the machine-readable part without having any opinions about how large the major version integer gets. (Again, maybe this is the culture around SemVer, not something from SemVer itself.)
EDIT: Less verbosely: SemVer seems to both dictate the breaking change versioning as well as making infrequent major bumps after 0.x.x. I think that is an overreach if you want your specification to be focused and uncontroversial, because in practice people will end up going back and forth about tradeoffs.
