Hey folks! Don't know why this is here. Hasn't been many changes to semver lately. I would like to get some going, but been pretty burned out after Rust. I'd love to bring the spec in line with the implementations, so it's gonna be a change in theory but not in practice.
Happy to answer any questions but won't be around the thread for a bit.
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 :)
hi, i posted this because i was impressed by semver. i didnt know u worked on the rust book. im extremely impressed. What are some tips about Rust that I could use? As a Rustacean myself, I really need help actually sticking to a project. What are some things that can make my code less verbose too?
I am not sure I can help with that :) Self control is hard, there's so many cool things to build.
What are some tips about Rust that I could use?
I'm sorry, this is too vague.
What are some things that can make my code less verbose too?
Not all kinds of verbosity are a bad thing. But usually there are libraries to help with this. For example, writing your own error implementations can be verbose, but thiserror can help with that.
Comments
Hey folks! Don't know why this is here. Hasn't been many changes to semver lately. I would like to get some going, but been pretty burned out after Rust. I'd love to bring the spec in line with the implementations, so it's gonna be a change in theory but not in practice.
Happy to answer any questions but won't be around the thread for a bit.
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 :)
Not a question but I’m still bitter that PEP440 is not more popular. It had great ideas that Semver does not implement.
hi, i posted this because i was impressed by semver. i didnt know u worked on the rust book. im extremely impressed. What are some tips about Rust that I could use? As a Rustacean myself, I really need help actually sticking to a project. What are some things that can make my code less verbose too?
Thank you!
I am not sure I can help with that :) Self control is hard, there's so many cool things to build.
I'm sorry, this is too vague.
Not all kinds of verbosity are a bad thing. But usually there are libraries to help with this. For example, writing your own error implementations can be verbose, but thiserror can help with that.
thank you so much for responding! this actually means a lot to me. if there isn't a library for something, should i write my own?
It certainly can't hurt, and you'll probably learn a lot while doing so :)
thank u so much. i am impressed by all of ur work, this is amazing wow.
Why are you this handsome. It's not fair