Related to rust, one thing I'd love to see semver clarify is that if you do what rust does, where you just make up your own rules and then claim you use semver, you're not using semver. If the scheme is major.minor.patch with 0.x.y meaning "not semver yet, the numbers can mean whatever someone wants them to", and something like rust goes "we use semver, except we've changed what the numbers mean", then the text on semver.org should have already made it clear that that's simply not using semver, and any claims that you are, are invalid.
It's not semver until you hit 1.0.0 and start following the major.minor.patch system. Until then, your promise to your users is that your use of 0.* indicates a prerelease, and that once 1.0.0 comes out, the version numbers will reflect major.minor.patch changes.
(and the unwillingness of some people who assign some special meaning to "reaching 1.0", somehow treating that number as more than a number, should literally be the sign that they don't want to use semver. It'd be great if the spec/site had a big, bold, "you are not your version number" that makes it clear that version numbers are intended for versioning, and that semver numbers are a utility. They don't hold special meaning beyond unambiguously denoting major.minor.patch transitions)
The major motivation I currently have is to make it more clear that this is not actually incorrect. Rust here does exactly what Ruby and JavaScript do as well. The semver spec is misleadingly written compared to the real-world implementations that have existed nearly as long as the spec has. Furthermore, choosing these semantics for ^ (which is not in the current semver spec at all, mind you: none of the ranges are) still is allowed even with a strict reading of Rule #4: it says MAY, not MUST. Less breakage than allowed is okay.
It's not semver until you hit 1.0.0
Semver describes pre-1.0.0 versions as well. That is what Rule #4 is about, in fact.
and the unwillingness of some people who assign some special meaning to "reaching 1.0",
I agree that this is often an issue. I myself advocated that Cargo start projects out at 1.0.0, like npm, rather than 0.1.0, like Bundler. I lost that battle.
However, sometimes this is due to practical reasons, and not people psyching themselves out over a specific version. For example, the libc crate in Rust will probably never 1.0.0; there can only be one version of it in a dependency tree, and it's so widely used. 0.1.0 -> 0.2.0 was already a mega painful transition, and Rust's ecosystem is vastly larger than it was when that happened.
It'd be great if the spec/site had a big, bold, "you are not your version number"
I fully agree that it would be great if people get over this, and I would like the next version of the spec to not emphasize 1.0.0 so much, but I doubt that some bold text is going to fix what is ultimately a psychological issue.
Semver describes pre-1.0.0 versions as well. That is what Rule #4 is about, in fact.
I know, but rule 4 doesn't mean anything if there is an explicit "we wont" intention to ever make switch to 1.0.0 - if you're never going to move past 0.*, you're not semver'ing, you're just using your own "looks like semver, might smell like semver, doesn't taste like semver" scheme.
I agree that this is often an issue. I myself advocated that Cargo start projects out at 1.0.0, like npm, rather than 0.1.0, like Bundler. I lost that battle.
I'm sorry to hear that =(
[...] but I doubt that some bold text is going to fix what is ultimately a psychological issue.
You'd be surprised how far the authority of a spec goes. A ton of people will have massive opinions until they're confronted with the spec, an authority they recognize, clearly stating that their interpretation is explicitly ruled out. Specs allow people to cede authority to it.
And of course, don't let any of that detract from a massive thanks for the semver.org effort, no one can deny it's been a net positive on versioning overall.
if you're never going to move past 0., you're not semver'ing,
Eh that's fair. I think that reality is often messier than this, people intend* to eventually release one, and then don't, for various reasons. But I get what you're saying, sure.
don't let any of that detract from a massive thanks for the semver.org effort,
Just to be clear, I have mostly inherited a commit bit, tried to get some work done, and failed. I fully agree, but those results are the work of other people :)
Comments
Related to rust, one thing I'd love to see semver clarify is that if you do what rust does, where you just make up your own rules and then claim you use semver, you're not using semver. If the scheme is major.minor.patch with 0.x.y meaning "not semver yet, the numbers can mean whatever someone wants them to", and something like rust goes "we use semver, except we've changed what the numbers mean", then the text on semver.org should have already made it clear that that's simply not using semver, and any claims that you are, are invalid.
It's not semver until you hit 1.0.0 and start following the major.minor.patch system. Until then, your promise to your users is that your use of 0.* indicates a prerelease, and that once 1.0.0 comes out, the version numbers will reflect major.minor.patch changes.
(and the unwillingness of some people who assign some special meaning to "reaching 1.0", somehow treating that number as more than a number, should literally be the sign that they don't want to use semver. It'd be great if the spec/site had a big, bold, "you are not your version number" that makes it clear that version numbers are intended for versioning, and that semver numbers are a utility. They don't hold special meaning beyond unambiguously denoting major.minor.patch transitions)
Hi there!
The major motivation I currently have is to make it more clear that this is not actually incorrect. Rust here does exactly what Ruby and JavaScript do as well. The semver spec is misleadingly written compared to the real-world implementations that have existed nearly as long as the spec has. Furthermore, choosing these semantics for ^ (which is not in the current semver spec at all, mind you: none of the ranges are) still is allowed even with a strict reading of Rule #4: it says MAY, not MUST. Less breakage than allowed is okay.
Semver describes pre-1.0.0 versions as well. That is what Rule #4 is about, in fact.
I agree that this is often an issue. I myself advocated that Cargo start projects out at 1.0.0, like npm, rather than 0.1.0, like Bundler. I lost that battle.
However, sometimes this is due to practical reasons, and not people psyching themselves out over a specific version. For example, the libc crate in Rust will probably never 1.0.0; there can only be one version of it in a dependency tree, and it's so widely used. 0.1.0 -> 0.2.0 was already a mega painful transition, and Rust's ecosystem is vastly larger than it was when that happened.
I fully agree that it would be great if people get over this, and I would like the next version of the spec to not emphasize 1.0.0 so much, but I doubt that some bold text is going to fix what is ultimately a psychological issue.
I know, but rule 4 doesn't mean anything if there is an explicit "we wont" intention to ever make switch to 1.0.0 - if you're never going to move past 0.*, you're not semver'ing, you're just using your own "looks like semver, might smell like semver, doesn't taste like semver" scheme.
I'm sorry to hear that =(
You'd be surprised how far the authority of a spec goes. A ton of people will have massive opinions until they're confronted with the spec, an authority they recognize, clearly stating that their interpretation is explicitly ruled out. Specs allow people to cede authority to it.
And of course, don't let any of that detract from a massive thanks for the semver.org effort, no one can deny it's been a net positive on versioning overall.
Eh that's fair. I think that reality is often messier than this, people intend* to eventually release one, and then don't, for various reasons. But I get what you're saying, sure.
Just to be clear, I have mostly inherited a commit bit, tried to get some work done, and failed. I fully agree, but those results are the work of other people :)