> We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their pr

> We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their project. I can see the desire for this from a code consumer's perspective, I'll argue that this is mostly impossible. New projects often start because there's a new problem (a software architecture, a set of algorithmic tools, etc.) with an inherent learning curve. The 0.x releases reflect the inherent instability of this real-world learning process. Switching to your proposed Semver' model implies that projects must use the compatibility modes (e.g. deprecate-before-removal as this post describes React adopting) of more mature software before their ideas are even partially baked. Many 0.x-era updates (e.g. x++) are near-complete rewrites of the API or sometimes even the entire nascent codebase. I'll hypothesize that a major contributing factor to successful projects gaining wide adoption is the ability go through that vital period of rapid churn.