4 ms·
I don’t think that makes much sense to say until they actually encounter a scenario where violating semver could be done and even be reasonable, and they active
by setr 5y ago
I don’t think that makes much sense to say until they actually encounter a scenario where violating semver could be done and even be reasonable, and they actively choose not to.
Pre-1.0 semver is fairly meaningless, so taking it seriously really amounts to… doing anything at all. There’s literally nothing to be backwards compatible with, or to announce incompatibility with. They’ve have no opportunity to show how seriously they take it.
- qchris 5y agoIs 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 agoTBH 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 agoRust 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.
- dnautics 5y agoExactly. The point is, now is the time to fuck around and find out, because when 1.0 comes there won't be any major changes to the language.
- setr 5y agoRight; but my point is that “they take it seriously” is something you can only evaluate when they have the chance not to. Right now, they can do whatever they want (except mark it 1.0.0) and uphold all semver rules. They can talk about it, but there’s nothing to do anyways. The real test is whether they bump it to v2 or withhold an important change because of semver violation.
- dnautics 5y agoyes of course that is true, but Andy is pretty vocal about encouraging people to iterate quickly now because there is a desire to keep semver, at least it's not an afterthought.
- kristoff_it 5y agoNot rushing to v1 is also important. There are plenty of benefits in reaching a "good looking" version asap.