3 ms·

Is this, like, actually true? I was under the impression semver is particularly useful during that stage because it (is supposed to) provides guarantees around

by qchris 5y ago

Is this, like, actually true? I was under the impression semver is particularly useful during that stage because it (is supposed to) provides guarantees around which things break and when. I know, for example, many foundational Rust libraries are technically pre-1.0, but because of the semver standards, users are able to use them consistently because they have an understanding of which updates are important and/or likely to break their existing code, even when the long-term 1.0 guarantees don't necessarily exist.

setr 5y ago
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
- kvark 5y ago
  Rust ecosystem uses a slightly modified semver: https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility https://doc.rust-lang.org/cargo/reference/resolver.html#semv... In this scheme, 0.x.y is compatible with 0.x.z, so developing pre-1.0 software is as strict for breaking changes as post-1.0, just the numbers are different. For this very reason, many crates don’t rush into 1.0 territory and are comfortable in pre-1.0 zone.

by qchris 5y ago

setr 5y ago

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

kvark 5y ago
Rust ecosystem uses a slightly modified semver: https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility https://doc.rust-lang.org/cargo/reference/resolver.html#semv... In this scheme, 0.x.y is compatible with 0.x.z, so developing pre-1.0 software is as strict for breaking changes as post-1.0, just the numbers are different. For this very reason, many crates don’t rush into 1.0 territory and are comfortable in pre-1.0 zone.