[otterley]

> Don’t vendor your dependencies.

The alternative seems worse: your own application's stability is now at risk against upstream changes that could break your code. Sure, you might not get a fix immediately, but I'd rather know I'm making a change because I need a fix than introducing instability and additional risk that I don't want to subject myself to. "If it ain't broke, don't fix it."

[skybrian]

I like Go's approach, which ensures that all upgrades happen when you choose to do some upgrades.

(For apps, a lock file will do it too.)

[cpeterso]

Taking dependency updating to the extreme, some Google projects adopt a "live at head" philosophy, where their projects depend on their dependencies' top-of-tree main commits, not a release branch:

https://chromium.googlesource.com/chromium/src/+/HEAD/third_...

[teddyh]

You can choose to either live at the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, as discussed here: <https://news.ycombinator.com/item?id=21785399>

(And surely you should have tests to verify all your own functionality after upgrading a dependency?)

[otterley]

That "should" is load bearing. Unfortunately thorough automated testing isn't frequently done by application teams, and even fewer automated testing of dependencies is done by them. Most developers assume, for better or worse, that testing of dependencies is the responsibility of their respective authors.