3 ms·

> How does not hinting your tools the rest of the time improve things? If the hints are sometimes incorrect, should we trust them? Isn't it the same release-v

> How does not hinting your tools the rest of the time improve things? If the hints are sometimes incorrect, should we trust them? Isn't it the same release-verification legwork either way? If so, what's the point of the hint? > Rust compatibility (thus versioning) is fairly fragile due to its relatively powerful type system, and yet: Yes, I'm speaking about SemVer, which was neither invented by nor solely implemented in Rust. I understand that this blog post is about SemVer in Rust. > Abandoning semver means making it worse 30 out of 31 times for a fragile language, or likely more (because you do not always use the thing that technically broke). Other languages generally have even stronger arguments in favor of semver. I read this as: tooling is required to verify a release does or does not break a contract defined by a library, regardless of versioning strategy. It's not like we're talking about 1 in a million here. > Anyone opposed to it does not know what they're talking about, or they're simply trolling, and it shows. Ahh yes. "I'm right and if you disagree you're wrong". The ultimate debate tactic. I'll skip the rest of this thread. Enjoy the day!

obi1kenobi 3y ago
> Isn't it the same release-verification legwork either way? No, as it turns out it very much is not even close to the same amount of legwork. > I read this as I don't think your attempt at a re-statement is accurate to the source. Also, "regardless of versioning strategy" is simply not an option in Rust, since the entire ecosystem is opinionated about how versions should work and overall everything works very well. This post is about taking something that is already very rare (though painful when it does happen!) and making it even more rare. It shows a concrete way to do so, and also shows that so far we've been "getting lucky" by experiencing breakage less often than we might have been, given the same code changes. In other words: `cargo update` today has a tiny chance of breaking your Rust project. But if everyone used `cargo-semver-checks` every time, as demonstrated by what the blog post's analysis caught, we'd reduce the number of accidentally-breaking releases by *3% of all releases*. That is an astoundingly high reduction, so coupled with good testing practices and other static checks (type system, borrow checker, etc.) it means that `cargo update` will be even more astonishingly unlikely to break your project.
Groxx 3y ago
Semver is a pragmatism, human-and-tooling thing. It works the vast majority of the time. Many, many studies across many languages repeatedly show it. There are flaws, but there are extremely clear benefits - most updates just work, automatically. It works so well most people don't even realize how much they're being protected from. So what are you gaining by abandoning it? You're losing a lot, if you're not gaining a lot in return then there's no reason to choose it. --- >Ahh yes. "I'm right and if you disagree you're wrong". The ultimate debate tactic. I agree in principle, but it is also simply true in some cases. It's like arguing against vaccines or range checks on arrays - there's a massive load of trolling or willful ignorance in semver debates. There can definitely be better systems, but none are used widely enough to be noteworthy to most, and most presented alternatives are laughably bad to anyone who has done anything but throw nonsense at the internet's wall and see what sticks. Some things are just not that complex, and armchair bullshitters can be spotted miles away.

obi1kenobi 3y ago

> Isn't it the same release-verification legwork either way? No, as it turns out it very much is not even close to the same amount of legwork. > I read this as I don't think your attempt at a re-statement is accurate to the source. Also, "regardless of versioning strategy" is simply not an option in Rust, since the entire ecosystem is opinionated about how versions should work and overall everything works very well. This post is about taking something that is already very rare (though painful when it does happen!) and making it even more rare. It shows a concrete way to do so, and also shows that so far we've been "getting lucky" by experiencing breakage less often than we might have been, given the same code changes. In other words: `cargo update` today has a tiny chance of breaking your Rust project. But if everyone used `cargo-semver-checks` every time, as demonstrated by what the blog post's analysis caught, we'd reduce the number of accidentally-breaking releases by *3% of all releases*. That is an astoundingly high reduction, so coupled with good testing practices and other static checks (type system, borrow checker, etc.) it means that `cargo update` will be even more astonishingly unlikely to break your project.

Groxx 3y ago

Semver is a pragmatism, human-and-tooling thing. It works the vast majority of the time. Many, many studies across many languages repeatedly show it. There are flaws, but there are extremely clear benefits - most updates just work, automatically. It works so well most people don't even realize how much they're being protected from. So what are you gaining by abandoning it? You're losing a lot, if you're not gaining a lot in return then there's no reason to choose it. --- >Ahh yes. "I'm right and if you disagree you're wrong". The ultimate debate tactic. I agree in principle, but it is also simply true in some cases. It's like arguing against vaccines or range checks on arrays - there's a massive load of trolling or willful ignorance in semver debates. There can definitely be better systems, but none are used widely enough to be noteworthy to most, and most presented alternatives are laughably bad to anyone who has done anything but throw nonsense at the internet's wall and see what sticks. Some things are just not that complex, and armchair bullshitters can be spotted miles away.