5 ms·

If I consume library X at version 1.2.3, develop my application, and then library X is upgraded to 1.2.4, should I pull in this new version? What about if it is

• jancsika 8y ago
  > 1. The author of the library has stated that there are no backwards incompatible API changes. What is my confidence in this assertion? Prefix all of my responses with, "If semver is to be meaningful to the developer." 1. Your confidence should be so high that an ongoing pattern of mismatch between statement and reality spells the end of that software project. 2. With the same level of confidence as above, yes. 3. I need clarification. Are you saying that a major version >= 1 of a dependency you rely upon in production returns a sorted list, but then a new bugfix version now outputs an unsorted list? 4. Performance, bugfixes, the ability to use new features with impunity. And of course my replies are idealistic and cannot work in a large number of extant development contexts. But let me throw the question back-- given your righteous skepticism, what in the world is the point of having three different version numbers if you cannot trust any of them without further in-depth research? If a bugfix can break one of your dev's assumptions about a poorly documented interface, what meaningful hierarchy could there be among the dots of semver? Why not have a single incrementing number? edit: clarification
  • mrgriffin 8y ago
    > 3. I need clarification. Are you saying that a major version >= 1 of a dependency you rely upon in production returns a sorted list, but then a new bugfix version now outputs an unsorted list? Not OP, but I believe they are saying that the API happens to return a sorted list (either for their particular inputs, or in general), but this was never a guarantee of the API (and was presumably not covered by tests), and so the package maintainers changed the implementation to no longer return a sorted list (maybe they found a faster algorithm). I have to say that I think this is a good case for having tests that are tied to particular versions, like in this comment: https://news.ycombinator.com/item?id=19138853 https://news.ycombinator.com/item?id=19138853 Or perhaps in this specific case the user of the library will add the test (to their own codebase) that checks the output is always sorted, and it will fail to upgrade to a version where this isn't true. In general I'd be pretty happy to see people write tests for the subset of behavior they require from a library, although I appreciate that's potentially a whole lot of work, particularly in ecosystems without property-based testing.
    • jancsika 8y ago
      Attempting to extend the "semver skeptic" OP's original questions: where would such information be represented in semver? Whatever probabilities you give to it appearing in the major/minor/bugfix slot, the point is that the skeptic dev cannot safely assume that it will appear in the major slot. If it doesn't appear in the major slot, that means there is a mismatch between what the package author/maintainer considers to be backwards-compatibility and what the author assumes it is. Given the sad state of FLOSS documentation, this is a common type of mismatch where bugs hide. That means the skeptic dev has to pin to some version that they've tested, only upgrading for a critical bug or some feature valuable enough to warrant the increased time building tests for the new version and hunting for "mismatch" bugs. I think that skepticism characterizes a critical mass of npm usage. If that is indeed the case then those devs do not trust the minor and bugfix slots to convey meaningful backwards-compatibility information. There might as well be a single incrementing version integer with a changelog at that point. Edit: clarification
  • deleted 8y ago
    [deleted]