TBH I had looked it up when writing the prior post to make sure I wasn’t just running off my own naivety From the spec[0]: > 4. Major version zero (0.y.z) is

TBH I had looked it up when writing the prior post to make sure I wasn’t just running off my own naivety From the spec[0]: > 4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. > 5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes. Which directly matches my expectations — the primary reason any project uses a version 0 (regardless of semver) is to specifically claim that they promise nothing — “no one should rely on this, and anyone who does is doing so at their own risk…” Version 1 is I think near-universally agreed to mean “this is production-ready” — where production is vague but roughly implies “If it doesn’t do what it says on the tin, it’s a bug”. Version 1+ meaning varies depending on the versioning scheme, but 0 & 1 are fairly universal. Of course, qualify everything with the standard “it’s open source so I don’t actually owe you jack shit” Any promise/expectation of stability in 0.x.y is outside the scope of semver, and communally is on you. Bevy for example breaks their APIs every 0.x release, and that’s perfectly fine & expected under semver. [0] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4