4 ms·

Why is semver expected? Isn't it well known to be a flawed practice yet?

by lugg 7y ago

jsjohnst 7y ago
> Isn't it well known to be a flawed practice yet? Care to explain? Why would using semantic versioning, something near universally accepted as a best practice, be flawed in your eyes?
- lugg 7y ago
  How can I explain something I clearly disagree with?
  - detaro 7y ago
    If you disagree with semver being flawed, why did you ask: > Isn't it well known to be a flawed practice yet? If you agree with that statement, why can't you explain why it is flawed?
    - lugg 7y ago
      That wasn't the question. The question was why do I think it's both flawed and universally accepted. Because it is, and it isn't? These are basic facts. Have you read the semver spec? Is your libraries new version compatible with my library? How can you know?
      - jsjohnst 7y ago
        > That wasn’t the question Yes, it was. While the grammar I used should be pretty clear on what I meant already, here’s an alternative version: Why would using semantic versioning (something near universally accepted as a best practice) be flawed in your eyes? Or more simply: Why would using semantic versioning be flawed in your eyes? > These are basic facts. Actually, they aren’t. It’s your opinion (not a fact) and you still haven’t provided a single drawback (flaw) to following semantic versioning despite repeated requests. > Have you read the semver spec? Yes, I have. More than once in fact. Have you? > Is your libraries new version compatible with my library? Assuming both authors follow semantic versioning faithfully and the previous minor/patch release worked, then yes, it very likely will be compatible. > How can you know? If both sides have a well defined API and the authors follow semantic versioning, you should have a good indication that way. That said, as the saying goes, “trust but verify”.
      - fluffything 7y ago
        > Because it is, and it isn't? > > These are basic facts. Those are not facts, those are claims. Facts are supported with data, and you haven't given any. The only fact you have actually provided is that you can't tell facts from claims apart, and that makes it very unlikely that you will be able to provide any actual facts that support your claims.
  - pohl 7y ago
    This is where the discipline of asking yourself “why” becomes useful.
- zzzcpan 7y ago
  It's a convention that cannot really be enforced by compiler or any tooling, it ultimately relies on humans following it, hence it will always be broken in some way for some users.
  - jsjohnst 7y ago
    Sure, I’ll give that it’s a very hard problem to enforce (not impossible, but very hard with virtually all current language implementations). That doesn’t negate the benefits of having a social contract (what semantic versioning is) that says you strive to do the right thing, even if you sometimes fail.
    - lugg 7y ago
      What benefits? Everyone else just maintains backwards compatibility. Why are you so such a snowflake? Nobody asked you to "improve" you library by breaking it.
      - beatgammit 7y ago
        Sometimes you need to break backwards compatibility to fix a security issue or implement a new, desired feature. Most often the breakage is small, but it's still nice to know as a library user when the build may break. Yes, try to avoid breaking backwards compatibility, but have some mechanism to handle the rare case when you do need to break guarantees. Most of the libraries I use that follow semver rarely break backwards compatibility, and it's still helpful to use semver to note bugfixes vs new features. New features can be a liability and introduce bugs, bugfixes are frequently quite safe, so it lets me know how much effort I should expect to spend testing when pulling in a new version. When I'm close to a release, I'll avoid new feature releases, but probably pull in bugfix releases.
      - jsjohnst 7y ago
        Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway. > Everyone else just maintains backwards compatibility. Name one piece of software of substantive size and with a history longer than a couple years, which never had a backwards compatibility break ever? Just in case you can name one, then name two instead. Contrary to your statement, 99.99999% of software has a backwards incompatible change at some point. What’s a good way to indicate that to your end users? Semantic versioning. > Nobody asked you to "improve" you library by breaking it. So if a major bug is found after release, one should never fix it? Fixing a bug could easily lead to a backwards incompatible break, if nothing else because someone was depending on that buggy behavior.
- virgilp 7y ago
  Disclaimer: I don’t think it’s _flawed_. It’s simple and useful But it has some flaws in some situations - I would describe it as “less than ideal”. Rich Hickey describes some problems here: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/Spec_ulation.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- kinjba11 7y ago
  Semantic versioning isn't a silver bullet, unfortunately, due to the 'Diamond Dependency Problem'. That is, A depends on B and C, but B and C depend on different versions of D. Easy to fix, until you scale that up to thousands of nodes in a dependency graph. This talk is one of the better ones about this: https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI
  - jsjohnst 7y ago
    > Semantic versioning isn't a silver bullet, unfortunately Nobody said it fixed all problems. Virtually all dependency management systems struggle with this problem, whether packages use semantic versioning or not.

Why is semver expected? Isn't it well known to be a flawed practice yet?

by lugg 7y ago

Why is semver expected? Isn't it well known to be a flawed practice yet?

> Isn't it well known to be a flawed practice yet? Care to explain? Why would using semantic versioning, something near universally accepted as a best practice, be flawed in your eyes?

lugg 7y ago
How can I explain something I clearly disagree with?
- detaro 7y ago
  If you disagree with semver being flawed, why did you ask: > Isn't it well known to be a flawed practice yet? If you agree with that statement, why can't you explain why it is flawed?
  - lugg 7y ago
    That wasn't the question. The question was why do I think it's both flawed and universally accepted. Because it is, and it isn't? These are basic facts. Have you read the semver spec? Is your libraries new version compatible with my library? How can you know?
    - jsjohnst 7y ago
      > That wasn’t the question Yes, it was. While the grammar I used should be pretty clear on what I meant already, here’s an alternative version: Why would using semantic versioning (something near universally accepted as a best practice) be flawed in your eyes? Or more simply: Why would using semantic versioning be flawed in your eyes? > These are basic facts. Actually, they aren’t. It’s your opinion (not a fact) and you still haven’t provided a single drawback (flaw) to following semantic versioning despite repeated requests. > Have you read the semver spec? Yes, I have. More than once in fact. Have you? > Is your libraries new version compatible with my library? Assuming both authors follow semantic versioning faithfully and the previous minor/patch release worked, then yes, it very likely will be compatible. > How can you know? If both sides have a well defined API and the authors follow semantic versioning, you should have a good indication that way. That said, as the saying goes, “trust but verify”.
    - fluffything 7y ago
      > Because it is, and it isn't? > > These are basic facts. Those are not facts, those are claims. Facts are supported with data, and you haven't given any. The only fact you have actually provided is that you can't tell facts from claims apart, and that makes it very unlikely that you will be able to provide any actual facts that support your claims.
- pohl 7y ago
  This is where the discipline of asking yourself “why” becomes useful.
zzzcpan 7y ago
It's a convention that cannot really be enforced by compiler or any tooling, it ultimately relies on humans following it, hence it will always be broken in some way for some users.
- jsjohnst 7y ago
  Sure, I’ll give that it’s a very hard problem to enforce (not impossible, but very hard with virtually all current language implementations). That doesn’t negate the benefits of having a social contract (what semantic versioning is) that says you strive to do the right thing, even if you sometimes fail.
  - lugg 7y ago
    What benefits? Everyone else just maintains backwards compatibility. Why are you so such a snowflake? Nobody asked you to "improve" you library by breaking it.
    - beatgammit 7y ago
      Sometimes you need to break backwards compatibility to fix a security issue or implement a new, desired feature. Most often the breakage is small, but it's still nice to know as a library user when the build may break. Yes, try to avoid breaking backwards compatibility, but have some mechanism to handle the rare case when you do need to break guarantees. Most of the libraries I use that follow semver rarely break backwards compatibility, and it's still helpful to use semver to note bugfixes vs new features. New features can be a liability and introduce bugs, bugfixes are frequently quite safe, so it lets me know how much effort I should expect to spend testing when pulling in a new version. When I'm close to a release, I'll avoid new feature releases, but probably pull in bugfix releases.
    - jsjohnst 7y ago
      Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway. > Everyone else just maintains backwards compatibility. Name one piece of software of substantive size and with a history longer than a couple years, which never had a backwards compatibility break ever? Just in case you can name one, then name two instead. Contrary to your statement, 99.99999% of software has a backwards incompatible change at some point. What’s a good way to indicate that to your end users? Semantic versioning. > Nobody asked you to "improve" you library by breaking it. So if a major bug is found after release, one should never fix it? Fixing a bug could easily lead to a backwards incompatible break, if nothing else because someone was depending on that buggy behavior.
virgilp 7y ago
Disclaimer: I don’t think it’s _flawed_. It’s simple and useful But it has some flaws in some situations - I would describe it as “less than ideal”. Rich Hickey describes some problems here: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/Spec_ulation.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
kinjba11 7y ago
Semantic versioning isn't a silver bullet, unfortunately, due to the 'Diamond Dependency Problem'. That is, A depends on B and C, but B and C depend on different versions of D. Easy to fix, until you scale that up to thousands of nodes in a dependency graph. This talk is one of the better ones about this: https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI
- jsjohnst 7y ago
  > Semantic versioning isn't a silver bullet, unfortunately Nobody said it fixed all problems. Virtually all dependency management systems struggle with this problem, whether packages use semantic versioning or not.