4 ms·

So every change is a breaking change? Not sure that helps anybody

SkyPuncher 3y ago
I agree. Semver isn’t perfect, but it gives you a general idea of how hard an upgrade might be. That’s even more true with the most popular of libraries. For example, Rails and React are the two most important dependencies in our system. They are extremely good about semver with major versions including highly detailed patch notes.
Groxx 3y ago
It definitely does not. v43 to v44: fixed "teh" in a comment v44 to v45: restructured the whole thing, steps for users to migrate are expected to be in the man-months for most projects Semver is a human convention that can also frequently help machines. It'd be nice if it were a machine system that also helped humans, but very very few compatibility systems achieve that. There are no other options currently to achieve this, and it works pretty well in practice. Use semver, don't make everyone else pay for your willful ignorance.
- 3np 3y ago
  And now you need to update from version 42 to 67 after not paying attention for 4 months because there's an emergency bugfix or crucial feature that you can't backport trivially. Have fun.
  - Groxx 3y ago
    They do have a backport for version 56, but it's in a branch named v62-backport-v56-githubusername-2023-asdf-try-2 and you have no way to discover that. Instead of choosing v56.1, because that would be semver.
    - 3np 3y ago
      That backport seems to use a nonpublished patched fork of a library that got replaced in between though, so no bueno there.
alex_lav 3y ago
But isn’t the point of this post to suggest that even if SemVer suggests a release isn’t breaking, they still are in practice? Such that, coding defensively, you have to assess whether a new version of a tool breaks regardless of SemVer or not. In which case, why bother with SemVer in the first place?
- deleted 3y ago
  [deleted]
- Groxx 3y ago
  How does not hinting your tools the rest of the time improve things? Rust compatibility (thus versioning) is fairly fragile due to its relatively powerful type system, and yet: >Around 1 in 31 releases had at least one semver violation 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, or in a way that notices the break). Other languages generally have even stronger arguments in favor of semver. It's not a "both sides" thing, semver wins by an absolute knockout in every conceivable way, and especially in practical day-to-day ways. Anyone opposed to it does not know what they're talking about, or they're simply trolling, and it shows. There could definitely be better systems, but "just don't use semver lol" is not one of them.
  - alex_lav 3y ago
    > 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!

I agree. Semver isn’t perfect, but it gives you a general idea of how hard an upgrade might be. That’s even more true with the most popular of libraries. For example, Rails and React are the two most important dependencies in our system. They are extremely good about semver with major versions including highly detailed patch notes.

Groxx 3y ago

It definitely does not. v43 to v44: fixed "teh" in a comment v44 to v45: restructured the whole thing, steps for users to migrate are expected to be in the man-months for most projects Semver is a human convention that can also frequently help machines. It'd be nice if it were a machine system that also helped humans, but very very few compatibility systems achieve that. There are no other options currently to achieve this, and it works pretty well in practice. Use semver, don't make everyone else pay for your willful ignorance.

3np 3y ago
And now you need to update from version 42 to 67 after not paying attention for 4 months because there's an emergency bugfix or crucial feature that you can't backport trivially. Have fun.
- Groxx 3y ago
  They do have a backport for version 56, but it's in a branch named v62-backport-v56-githubusername-2023-asdf-try-2 and you have no way to discover that. Instead of choosing v56.1, because that would be semver.
  - 3np 3y ago
    That backport seems to use a nonpublished patched fork of a library that got replaced in between though, so no bueno there.

alex_lav 3y ago

But isn’t the point of this post to suggest that even if SemVer suggests a release isn’t breaking, they still are in practice? Such that, coding defensively, you have to assess whether a new version of a tool breaks regardless of SemVer or not. In which case, why bother with SemVer in the first place?

deleted 3y ago
[deleted]
Groxx 3y ago
How does not hinting your tools the rest of the time improve things? Rust compatibility (thus versioning) is fairly fragile due to its relatively powerful type system, and yet: >Around 1 in 31 releases had at least one semver violation 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, or in a way that notices the break). Other languages generally have even stronger arguments in favor of semver. It's not a "both sides" thing, semver wins by an absolute knockout in every conceivable way, and especially in practical day-to-day ways. Anyone opposed to it does not know what they're talking about, or they're simply trolling, and it shows. There could definitely be better systems, but "just don't use semver lol" is not one of them.
- alex_lav 3y ago
  > 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!