6 ms·

> Minimal Version Selection Means no security fixes at the price of, well, minor developer inconvenience? What is the inconvenience, exactly? > ...tomorrow th

> Minimal Version Selection Means no security fixes at the price of, well, minor developer inconvenience? What is the inconvenience, exactly? > ...tomorrow the same sequence of commands you ran today would produce a different result. I mean, I guess this is technically true. But seems like it shouldn't be an issue in practice as the API you're calling shouldn't have changed, just the implementation. If it has changed, then downgrade the dependency?

bbatha 9y ago
These issues all seem to be solved by lockfiles, which are a part of the dep tool. Why ditch them here? It seems like rsc seems to be hinting at an argument for simplicity. But the long history of package managers, and my anecdotal experience confirms, that you're going to need a lock file no matter what. Good versioning practices are not enough, npm versions 1-4 prove that you need locking, and it must be on by default to make reproducible software. Minimum versioning will likely be better than the newest version for stability, but its not enough.
- stormbeta 9y ago
  Not only that, but locking allows for what is IMO the best way to handle this through CI: Always run your builds with maximal version selection in CI (unlocked), and lock the new versions in if it passes all tests, otherwise leave the previous locked versions and flag it for review.
binarycrusader 9y ago
As a long-time maintainer of various packaging systems (and co-author of one): I find myself wholly in agreement with the idea that maximal version selection is appropriate for operating systems and general software components, but not necessarily desirable for a build system. When you consider the evaluation of a dependency graph in the context of a SAT solver, you realize that the solver would consider both a minimal and maximal version as potentially satisfying the general constraints found in a dependency graph. Whether you then optimize the solution for a minimal or maximal version becomes a matter of policy, not correctness. The security concern can be appropriately addressed by increasing the minimum version required in the appropriate places. With all of that said, I think that Go's potential decision to optimize for minimal version selection is likely to be considered a bug by many because it will not be the "accepted" behavior that most are accustomed to. In particular, I can already imagine a large number of developers adding a fix, expecting others to automatically pick it up in the next build, and being unpleasantly surprised when that doesn't happen. This is an interesting experiment at the least, but I hope they make the optimizing choice for minimal/maximal version configurable (although I doubt they will).
- readams 9y ago
  We can only hope they'll at least have a tool that you can run that will bump up all the versions to specify the latest. But then of course that will make solving dependencies a lot harder since it's much more likely you'll get an unsolvable set of deps. It's hard to see how this could ever help anything. Lock files also have the major advantage that you have a hash of the thing you're downloading so you're not depending on the maintainer not e.g. force pushing something.
  - mook 9y ago
    Because only the minimum version can be specified, you will always get a solvable set of deps. Those deps might not build but they will be solvable.
- munificent 9y ago
  > When you consider the evaluation of a dependency graph in the context of a SAT solver, you realize that the solver would consider both a minimal and maximal version as potentially satisfying the general constraints found in a dependency graph. Whether you then optimize the solution for a minimal or maximal version becomes a matter of policy, not correctness. I believe rsc is hoping they can avoid the need for a SAT solver entirely by going with minimum versions (and, implied, not allowing a newer package to be published with a lower version number).
  - uluyol 9y ago
    Actually, I think the SAT solver is avoided by making the only version constraints of the form <=. Using the min version appears to eschew the need for lock files. Want to upgrade? Bump your min version.
    - binarycrusader 9y ago
      One potential problem with dependency resolution that focuses solely on minimal or maximal-bound resolution is that it usually ignores the untested version combination problems. That is, a given version that satisfies a version bound may not have necessarily been tested with all of the different combinations of versions of components it is used with. It will be interesting to see how minimal version selection interacts with that particular challenge. For a build system it may matter much less than an operating system.
wtetzner 9y ago
> I mean, I guess this is technically true. But seems like it shouldn't be an issue in practice as the API you're calling shouldn't have changed, just the implementation. If it has changed, then downgrade the dependency? And if the new implementation has a new bug, you might be screwed. It worked last week, but not this week. How do I get back to the working version?
- lsaferite 9y ago
  Use 'git bisect' or some similar tool to walk back and find the point where the lock file change triggered the bug?
  - wtetzner 9y ago
    If you have a lock file, there's no problem. I was arguing about what happens when there isn't a lock file. I may have inferred something that wasn't in the original comment, by reading too many of the other comments on this page.
    - makapuf 9y ago
      Sort but given that we're relying on git mostly, what are the advantages of lock files over submodules/subtrees ?
      - wtetzner 9y ago
        Well, that would lock all of the projects into git. What if some libraries are in git, and others are in mercurial and darcs? I think it’s better to have a package manager that’s not reliant on a particular source control system.

bbatha 9y ago

These issues all seem to be solved by lockfiles, which are a part of the dep tool. Why ditch them here? It seems like rsc seems to be hinting at an argument for simplicity. But the long history of package managers, and my anecdotal experience confirms, that you're going to need a lock file no matter what. Good versioning practices are not enough, npm versions 1-4 prove that you need locking, and it must be on by default to make reproducible software. Minimum versioning will likely be better than the newest version for stability, but its not enough.

stormbeta 9y ago
Not only that, but locking allows for what is IMO the best way to handle this through CI: Always run your builds with maximal version selection in CI (unlocked), and lock the new versions in if it passes all tests, otherwise leave the previous locked versions and flag it for review.

binarycrusader 9y ago

As a long-time maintainer of various packaging systems (and co-author of one): I find myself wholly in agreement with the idea that maximal version selection is appropriate for operating systems and general software components, but not necessarily desirable for a build system. When you consider the evaluation of a dependency graph in the context of a SAT solver, you realize that the solver would consider both a minimal and maximal version as potentially satisfying the general constraints found in a dependency graph. Whether you then optimize the solution for a minimal or maximal version becomes a matter of policy, not correctness. The security concern can be appropriately addressed by increasing the minimum version required in the appropriate places. With all of that said, I think that Go's potential decision to optimize for minimal version selection is likely to be considered a bug by many because it will not be the "accepted" behavior that most are accustomed to. In particular, I can already imagine a large number of developers adding a fix, expecting others to automatically pick it up in the next build, and being unpleasantly surprised when that doesn't happen. This is an interesting experiment at the least, but I hope they make the optimizing choice for minimal/maximal version configurable (although I doubt they will).

readams 9y ago
We can only hope they'll at least have a tool that you can run that will bump up all the versions to specify the latest. But then of course that will make solving dependencies a lot harder since it's much more likely you'll get an unsolvable set of deps. It's hard to see how this could ever help anything. Lock files also have the major advantage that you have a hash of the thing you're downloading so you're not depending on the maintainer not e.g. force pushing something.
- mook 9y ago
  Because only the minimum version can be specified, you will always get a solvable set of deps. Those deps might not build but they will be solvable.
munificent 9y ago
> When you consider the evaluation of a dependency graph in the context of a SAT solver, you realize that the solver would consider both a minimal and maximal version as potentially satisfying the general constraints found in a dependency graph. Whether you then optimize the solution for a minimal or maximal version becomes a matter of policy, not correctness. I believe rsc is hoping they can avoid the need for a SAT solver entirely by going with minimum versions (and, implied, not allowing a newer package to be published with a lower version number).
- uluyol 9y ago
  Actually, I think the SAT solver is avoided by making the only version constraints of the form <=. Using the min version appears to eschew the need for lock files. Want to upgrade? Bump your min version.
  - binarycrusader 9y ago
    One potential problem with dependency resolution that focuses solely on minimal or maximal-bound resolution is that it usually ignores the untested version combination problems. That is, a given version that satisfies a version bound may not have necessarily been tested with all of the different combinations of versions of components it is used with. It will be interesting to see how minimal version selection interacts with that particular challenge. For a build system it may matter much less than an operating system.

wtetzner 9y ago

> I mean, I guess this is technically true. But seems like it shouldn't be an issue in practice as the API you're calling shouldn't have changed, just the implementation. If it has changed, then downgrade the dependency? And if the new implementation has a new bug, you might be screwed. It worked last week, but not this week. How do I get back to the working version?

lsaferite 9y ago
Use 'git bisect' or some similar tool to walk back and find the point where the lock file change triggered the bug?
- wtetzner 9y ago
  If you have a lock file, there's no problem. I was arguing about what happens when there isn't a lock file. I may have inferred something that wasn't in the original comment, by reading too many of the other comments on this page.
  - makapuf 9y ago
    Sort but given that we're relying on git mostly, what are the advantages of lock files over submodules/subtrees ?
    - wtetzner 9y ago
      Well, that would lock all of the projects into git. What if some libraries are in git, and others are in mercurial and darcs? I think it’s better to have a package manager that’s not reliant on a particular source control system.