
The pain that minimal version selection solves - ngaut
https://about.sourcegraph.com/blog/the-pain-that-minimal-version-selection-solves/
======
AndrewDucker
It does solve that pain.

But it doesn't solve the "A dependency of a dependency has a massive security
hole in it, and there's a patched version which has just been released" pain.

Which I'd argue is more important.

~~~
kjksf
Here's a problem MSV guards against: a new checkin in a dependency introduces
a massive security hole and it silently gets pulled into your project.

The "security issue" argument is bogus because while new code can fix bugs it
can also introduce new bugs.

Every competent dev shop has code reviews.

A code review exists because you don't trust your coworkers to not introduce
bugs.

But somehow you're ok with people you don't know to effectively check in code
into your code base without as much as running a smoke test.

~~~
wereHamster
> […] silently gets pulled into your project.

The core issue that caused all of OPs problems was that Renovate Bot claimed
to have only updated one dependency (@sourcegraph/codeintellify), but also
updated another, unrelated one (sanitize-html). If you can't trust the tools
around you not to lie to your face, all bets are off.

It doesn't matter whether our tools follow MSV or the opposite (LSV – Latest
Version Selection?). We should always pin our dependencies to exact versions,
and explicitly update them as needed. Renovate Bot (and its alternatives)
attempt to automate that part. They send you notifications or even open pull
requests, you can inspect the changelog of your dependencies and decide for
yourself if the update is necessary (eg. because of security reasons) or if
you prefer not to update out of fear of breaking something. Right now it seems
Renovate Bot sucks at that, and should be improved accordingly.

~~~
nicksnyder
Renovate Bot didn't do anything special. It ran exactly the same npm command
that I would have run on the command line (update the single dependency),
which would have produced the exact same result.

~~~
wereHamster
> Renovate Bot didn't do anything special.

Maybe it /should/ do something special though. Maybe it should stop using npm.

If it says "I updated package X" and it really updated X /and/ Y, then it
didn't do what it promised. Maybe it should say "I updated package X and maybe
also others I don't know…" that would be more accurate to how it currently
works.

~~~
nicksnyder
This pain isn’t really about Renovate Bot. You can pretend that it doesn’t
exist or that your project isn’t using it. I should still be able to update a
single dependency without updating unrelated things.

------
TheCoelacanth
> avoids solving Version-SAT, which is NP-Complete

This is just a terrible argument. Sure the problem is NP-Complete to find an
optimal solution for the general case, but you don't need to do that. You need
to find a good-enough solution for the cases that people actually use.
Heuristics for that problem are plenty fast and even finding the optimal
solution is fast enough for most of the problems people are actually trying to
use.

~~~
littlestymaar
Yeah, this argument is ridiculous. It's like arguing that people shouldn't
have individual homes with garden because lawn mowing is NP-complete…

(Not that I'm saying individual homes are a good idea in general, but the NP-
complete argument is pretty dumb).

------
jblow
This isn't really about minimal version selection. It's about how it is bad
for your code to change behind your back ... which is a much more general and
widely-applicable point.

~~~
dajohnson89
right.

>Renovate Bot noticed that there was a new version of codeintellify so it
helpfully created a pull request to update our main repository to
codeintellify 3.6.0.

while this sounds really cool and I'll check it out later, automatically
updating your code just because a dependency has a new version seems like a
REALLY bad idea.

~~~
nicksnyder
It doesn't happen automatically if you don't want it to (and it didn't happen
automatically in this case).

The value here is that it notifies you if an update is available (by opening a
pull request), automatically tests the new dependency (when CI runs on your
pull request), and makes it easy for you to apply the update if you want (by
merging the pull request).

------
bouke
It looks like the major problem was that NPM updated an inrelated package,
despite a lock file. I would classify this as rather unexpected behaviour. I
don’t see why that’s relevant to dependency resolution in situations where
there’s no lock file.

~~~
twic
The fix for this problem is not a whole new philosophy of version selection,
it's being more sensible in implementing the current one.

Do any of Yarn, Bundler, or Cargo have this behaviour?

~~~
felixfbecker
Yarn has the same issue (it used to do shallow updates, but this was changed
due to community demand, and now theres the demand to change it back again)

------
jules
This is the opposite of the monorepo philosophy: everyone always uses the most
recent version of the code to minimise hassle. I wonder if minimal version
selection works nicely initially, but becomes more of a hassle over time
because you're basically procrastinating on moving to newer versions of your
dependencies. On the other hand, package managers should not _silently_
upgrade packages behind your back.

------
ainar-g
>I was upset because the design of NPM assumes things that just aren't true in
general:

>People perfectly understand and apply semantic versioning (see also:
compatible versioning).

Doesn't _any_ dependency management tool assume that _some_ form of versioning
is followed strictly? Go modules have another assumption besides that one, the
Semantic Import Versioning principle.

I understand OP's pain, but it seems to stem from bad design decisions made by
NPM authors, and doesn't have a lot to do with Minimal Version Selection.

~~~
nicksnyder
NPM specially assumes that "patch versions are safer to update than minor or
major version". MVS doesn't make that assumption.

> it seems to stem from bad design decisions made by NPM authors

Yep.

> doesn't have a lot to do with Minimal Version Selection

The pain I experienced has nothing to do with MVS (because npm doesn't use
MVS). The observation of the post is that my pain would not have happened with
MVS. No more, no less.

~~~
felixfbecker
> NPM specially assumes that "patch versions are safer to update than minor or
> major version".

I don't see where that assumption is baked into npm - the creator of a package
declares the dependency constraints, so they are the ones making the choice
which versions can be trusted well to work. You could pin all dependencies but
then users would need to download tons of duplicate dependencies because of
slight version differences everywhere. So it's a tradeoff, but the user makes
it, not npm.

~~~
nicksnyder
Rephrased:

npm’s design incentivizes projects to assume “patch versions are safer to
update than minor versions are safer to update than major versions” to avoid
dependency duplication.

Such incentives do not exist with MVS because all that is required is a total
ordering and there is no duplication within a major version of a module.

------
falcor84
How about if we had a feedback loop between the the continuous
integration/delivery system and the dependency version lock file?

It would probably be very difficult to set up, but I imagine it could start by
testing the minimal version, and if that works well, then do a binary search
to find the latest versions of all dependencies that still work well. In the
case of an exception stack trace, it could perhaps find the offensive
dependency quickly, but even if not, a brute force binary search should still
work.

~~~
jacques_chester
I think that once such systems are set up and have reached parity with the
most recent releases of dependencies, the business of keeping up is much
easier, which makes it more likely to happen.

We've all been in the situation where we fell behind some dependency and, upon
trying to upgrade, found that we were so far behind that everything was broken
in this-will-take-weeks-to-fix ways. That kind of work tends to get shunted
into the too hard pile, where it generally only gets harder. Eventually the
codebase ossifies around a very particular dependency set that can't be
upgraded without stopping feature development.

The fact that it may be carrying a stew of published vulnerabilities tends not
to be enough to trigger a change: work to upgrade is concrete, immediate and
costly. Exploited vulnerabilities are probabilistic, sometime in the future
and not taken from the current budget.

In practice stuff is kept up to date by rigid process discipline or by
automation. Of the two, automation is more likely to be successful and
_sustained_.

