5 ms·

The problem of semver is that everyone interprets the compatibility differently. There are some language-supported criteria, but that does not cover all importa

The problem of semver is that everyone interprets the compatibility differently. There are some language-supported criteria, but that does not cover all important use cases. In addition, any reasonable compatibility criteria might be impossible for large enough softwares---every revision can be potentially major in the semver terminology and it won't deliver much value to the user anyway. The calender versioning is useful for such cases.

sametmax 8y ago
I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare. Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.
- lifthrasiir 8y ago
  I think the language-backed semver can be useful (I really want Cargo to support this mode!). The general unguided semver seems less useful. I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).
  - lugg 8y ago
    This is my issue with semver. I don't care about minor non breaking change, just give me the latest. Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right? So lib: 1.* Should be fine, right? But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?
    - beatgammit 8y ago
      Sometimes breaking backwards compatibility is necessary. For example, if a function in a standard library has an error case that the initial version ignored (happened in Go), you can't start emitting errors when you used to guarantee that it wouldn't error. Or if there's a fundamental flaw in a function that cannot be fixed without a signature change. People ignore deprecation warnings, so the best way forward is often to break compatibility. I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. And you should try to have a bridge between old and new versions (e.g. Rust's "editions" seem like a good idea).
      - Pfhreak 8y ago
        Then it should be a major version change, right?
      - lugg 8y ago
        > People ignore deprecation warnings, so the best way forward is often to break compatibility. People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me? Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one. > the best way forward is often to break compatibility. This is NEVER the best way forward, this is some next level idiotic shit. > I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me. If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad. > It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.
        paulddraper 8y ago
        > Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one. That is literally what a version is.
  - qes 8y ago
    > you simply rename That sounds like an awful idea that will result in people adding version information to the name, not to mention destroying discoverability.
- Certhas 8y ago
  It seems like in this case you want to version API and program separately. API changes aren't the only thing people care about or that should be communicated in a version number. So semver would not just be "not perfect" but be actively misleading.
  - cwilkes 8y ago
    Then have a semver for the two different parts. Ie “version 3.3.1 of Awesome Server supporting the 2.x api as well as 3.1.x”
- stonogo 8y ago
  You should be reading it as "the problem with semver is that it does not solve the problem it purports to solve." An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.
  - fwip 8y ago
    An 80% solution means you have 80% fewer unexpected breakages.
  - eikenberry 8y ago
    Are you saying that knowing that there is an 80% starting chance of it not breaking anything is not any better not knowing that? That knowing that the devs don't think anything will break or not is worthless? And that is not counting the times when they do bump the major version to tell you it will probably break something. The 100% solution you imply as a strawman here doesn't exist and some information is better than no information. And no one said Semver means you don't test, it just guides you on the expected behavior of the new release.
  - fgonzag 8y ago
    > An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." Maybe if you deploy directly to production before any testing is done.
andrewingram 8y ago
I've seen this happen with Babel a few times. They've released bugfix releases which fixed a slightly incorrect implementation of a spec, which ended up breaking loads of peoples builds (this was before npm/yarn had a decent way to lock dependencies). Turns out, compilers have a really high bar for what can be considered a non-breaking change. Generally though, I think for end user software, a "breaking" change is one that requires the user to relearn something, i.e it breaks an existing mental model.

sametmax 8y ago

I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare. Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.

lifthrasiir 8y ago
I think the language-backed semver can be useful (I really want Cargo to support this mode!). The general unguided semver seems less useful. I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).
- lugg 8y ago
  This is my issue with semver. I don't care about minor non breaking change, just give me the latest. Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right? So lib: 1.* Should be fine, right? But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?
  - beatgammit 8y ago
    Sometimes breaking backwards compatibility is necessary. For example, if a function in a standard library has an error case that the initial version ignored (happened in Go), you can't start emitting errors when you used to guarantee that it wouldn't error. Or if there's a fundamental flaw in a function that cannot be fixed without a signature change. People ignore deprecation warnings, so the best way forward is often to break compatibility. I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. And you should try to have a bridge between old and new versions (e.g. Rust's "editions" seem like a good idea).
    - Pfhreak 8y ago
      Then it should be a major version change, right?
    - lugg 8y ago
      > People ignore deprecation warnings, so the best way forward is often to break compatibility. People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me? Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one. > the best way forward is often to break compatibility. This is NEVER the best way forward, this is some next level idiotic shit. > I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me. If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad. > It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.
      - paulddraper 8y ago
        > Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one. That is literally what a version is.
- qes 8y ago
  > you simply rename That sounds like an awful idea that will result in people adding version information to the name, not to mention destroying discoverability.
Certhas 8y ago
It seems like in this case you want to version API and program separately. API changes aren't the only thing people care about or that should be communicated in a version number. So semver would not just be "not perfect" but be actively misleading.
- cwilkes 8y ago
  Then have a semver for the two different parts. Ie “version 3.3.1 of Awesome Server supporting the 2.x api as well as 3.1.x”
stonogo 8y ago
You should be reading it as "the problem with semver is that it does not solve the problem it purports to solve." An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.
- fwip 8y ago
  An 80% solution means you have 80% fewer unexpected breakages.
- eikenberry 8y ago
  Are you saying that knowing that there is an 80% starting chance of it not breaking anything is not any better not knowing that? That knowing that the devs don't think anything will break or not is worthless? And that is not counting the times when they do bump the major version to tell you it will probably break something. The 100% solution you imply as a strawman here doesn't exist and some information is better than no information. And no one said Semver means you don't test, it just guides you on the expected behavior of the new release.
- fgonzag 8y ago
  > An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." Maybe if you deploy directly to production before any testing is done.

andrewingram 8y ago

I've seen this happen with Babel a few times. They've released bugfix releases which fixed a slightly incorrect implementation of a spec, which ended up breaking loads of peoples builds (this was before npm/yarn had a decent way to lock dependencies). Turns out, compilers have a really high bar for what can be considered a non-breaking change. Generally though, I think for end user software, a "breaking" change is one that requires the user to relearn something, i.e it breaks an existing mental model.