5 ms·

Here's a hypothetical feature of all package managers: * for all stable packages requested by the user, always upgrade to the most recent stable version that h

Here's a hypothetical feature of all package managers: * for all stable packages requested by the user, always upgrade to the most recent stable version that has the same major number as the one currently installed Can npm, apt, cargo, guix, etc. safely do this presently for the set of packages that use semver? If the answer is no, then what is the value to using semver?

spenczar5 8y ago
What does "safely do this" mean here?
shawnz 8y ago
> If the answer is no, then what is the value to using semver? So that humans can get an approximate idea of the pain involved with any particular version upgrade. It doesn't need to be fully automated to be useful. Plus, just because it can't be fully automated now doesn't mean that it won't be in the future.
moreira 8y ago
They... should be able to. Per SemVer rules you should be able to do just this. As an example, you should be able to upgrade from 2.0.0 to 2.25.99 without a single concern, because 2.0.Z is always backward-compatible bugfixes, 2.Y.Z means new features in a backward-compatible manner, and if -anything- ever breaks, then the major version would change, and you wouldn't automatically be upgraded to it. The only time that the answer would be "no" is if the project advertising itself as using SemVer breaks the expectation, since you have to trust that the developer actually knows how to use SemVer.
- alasdair_ 8y ago
  Let's say someone releases 1.2.3 and then, later, we realize that there was an obscure breaking change. Is the solution to release 2.0.0 and just hope that people realize the old version was broken? Or to release 1.2.4 with a fix that makes the change non-breaking again?
  - steveklabnik 8y ago
    https://semver.org/#what-do-i-do-if-i-accidentally-release-a-backwards-incompatible-change-as-a-minor-version https://semver.org/#what-do-i-do-if-i-accidentally-release-a...
    - jmartinpetersen 8y ago
      How am I, that by way of misfortune and bad timing, ended up depending on the obscure "feature" added in 1.2.3, to know that upgrading to 1.2.4 will actually break my thing?
      - steveklabnik 8y ago
        You can't. The situation isn't ideal, of course, but stuff happens. Nobody's perfect.
        jancsika 8y ago
        That's certainly true. But I'd rather have less helpful information than wrong information in a version number. For example-- a single incrementing version number ostensibly conveys less meaning than semver. If I release 43 after 42, there's no way for the user to tell if the API has broken in between. They must read a changelog. Most importantly, the only way for author/user to make an incorrect assumption about that number is if 43 is _exactly_ the same as 42. With semver we suddenly must care deeply whether the author got the user's expectations correct with regard to three seemingly separate categories of information. (And this with the current state of FLOSS documentation-- not sure if proprietary is any better in this regard.) What common practice tells me is that very few projects trust an author's assertion to the minimal level needed to automatically upgrade on a non-breaking bugfix release. Here, we're even discussing the situation where there isn't even an author/user misunderstanding of the API. If the author screws up a release, that wrong information is encoded directly into the semantic version. That's objectively wrong information, where there would have been no wrong information at all if one had only used a single incrementing integer. I'm not really arguing for a single incrementing integer, that's just an example to explain my point. What I would rather have is version information that conveys meaning reliably within the current universe of developer distrust of packages. I think that means something restrictive and modest like what "patch" does for patching-- e.g., mechanically do a job, warn if something looked slightly out of place, and bail otherwise. I guess another way to say it is that I do not want to rely upon an author's opinion of their code at all. Instead I want a tool to tell me what it can, when it can, and then goad me into reading the code when it can't tell me any more. Edit: clarification
Skunkleton 8y ago
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 upgraded to 1.3.1? The answer is maybe, but there are a few questions that need answers first: 1. The author of the library has stated that there are no backwards incompatible API changes. What is my confidence in this assertion? 2. In asserting that there are no backwards-incompatible changes, they have asserted that there is no new behavior as the result of bugs. Am I sure of that? 3. By stating my application is using v1.2.3, I am stating that I am _correctly_ using the published API. Am I? For example what if an API returned a sorted list, but that was not a guarantee of that API? 4. Are there benefits to upgrading that make the risks above worthwhile?
- 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.
lalaithion 8y ago
With cargo: cargo add foo This command will install the current version of foo, and add it to your config file. Then, cargo update will update your package to the highest available version that doesn't bump the major number.

spenczar5 8y ago

What does "safely do this" mean here?

shawnz 8y ago

> If the answer is no, then what is the value to using semver? So that humans can get an approximate idea of the pain involved with any particular version upgrade. It doesn't need to be fully automated to be useful. Plus, just because it can't be fully automated now doesn't mean that it won't be in the future.

moreira 8y ago

They... should be able to. Per SemVer rules you should be able to do just this. As an example, you should be able to upgrade from 2.0.0 to 2.25.99 without a single concern, because 2.0.Z is always backward-compatible bugfixes, 2.Y.Z means new features in a backward-compatible manner, and if -anything- ever breaks, then the major version would change, and you wouldn't automatically be upgraded to it. The only time that the answer would be "no" is if the project advertising itself as using SemVer breaks the expectation, since you have to trust that the developer actually knows how to use SemVer.

alasdair_ 8y ago
Let's say someone releases 1.2.3 and then, later, we realize that there was an obscure breaking change. Is the solution to release 2.0.0 and just hope that people realize the old version was broken? Or to release 1.2.4 with a fix that makes the change non-breaking again?
- steveklabnik 8y ago
  https://semver.org/#what-do-i-do-if-i-accidentally-release-a-backwards-incompatible-change-as-a-minor-version https://semver.org/#what-do-i-do-if-i-accidentally-release-a...
  - jmartinpetersen 8y ago
    How am I, that by way of misfortune and bad timing, ended up depending on the obscure "feature" added in 1.2.3, to know that upgrading to 1.2.4 will actually break my thing?
    - steveklabnik 8y ago
      You can't. The situation isn't ideal, of course, but stuff happens. Nobody's perfect.
      - jancsika 8y ago
        That's certainly true. But I'd rather have less helpful information than wrong information in a version number. For example-- a single incrementing version number ostensibly conveys less meaning than semver. If I release 43 after 42, there's no way for the user to tell if the API has broken in between. They must read a changelog. Most importantly, the only way for author/user to make an incorrect assumption about that number is if 43 is _exactly_ the same as 42. With semver we suddenly must care deeply whether the author got the user's expectations correct with regard to three seemingly separate categories of information. (And this with the current state of FLOSS documentation-- not sure if proprietary is any better in this regard.) What common practice tells me is that very few projects trust an author's assertion to the minimal level needed to automatically upgrade on a non-breaking bugfix release. Here, we're even discussing the situation where there isn't even an author/user misunderstanding of the API. If the author screws up a release, that wrong information is encoded directly into the semantic version. That's objectively wrong information, where there would have been no wrong information at all if one had only used a single incrementing integer. I'm not really arguing for a single incrementing integer, that's just an example to explain my point. What I would rather have is version information that conveys meaning reliably within the current universe of developer distrust of packages. I think that means something restrictive and modest like what "patch" does for patching-- e.g., mechanically do a job, warn if something looked slightly out of place, and bail otherwise. I guess another way to say it is that I do not want to rely upon an author's opinion of their code at all. Instead I want a tool to tell me what it can, when it can, and then goad me into reading the code when it can't tell me any more. Edit: clarification

Skunkleton 8y ago

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 upgraded to 1.3.1? The answer is maybe, but there are a few questions that need answers first: 1. The author of the library has stated that there are no backwards incompatible API changes. What is my confidence in this assertion? 2. In asserting that there are no backwards-incompatible changes, they have asserted that there is no new behavior as the result of bugs. Am I sure of that? 3. By stating my application is using v1.2.3, I am stating that I am _correctly_ using the published API. Am I? For example what if an API returned a sorted list, but that was not a guarantee of that API? 4. Are there benefits to upgrading that make the risks above worthwhile?

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.

lalaithion 8y ago

With cargo: cargo add foo This command will install the current version of foo, and add it to your config file. Then, cargo update will update your package to the highest available version that doesn't bump the major number.