3 ms·

I semi-disagree. The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dep

I semi-disagree. The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. > When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code. The problem is having a project with 1,000+ dependencies that are apparently such low quality that their authors issue build-breaking changes daily.

snarfy 9y ago
If you've ever done web development and peeked into your node_modules folder you'll understand this is a serious problem.
KallDrexx 9y ago
> The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. I'd argue dependencies should be manually updated constantly. While version pinning does allow you to accrue technical debt if your team has discipline it does allow you to manage the upgrade process and understand the impacts of a dependency upgrade. Even without obvious API changes it's possible that the implementation details of a library's method can cause your code to function differently, which can be caused by the introduction of a bug, the fixing of a bug your code didn't realize was a bug, or any minor quirks that may change between versions. When you manually upgrade you know exactly what to test and what to look for because (presumably) the person doing the dependency upgrade is someone who knows how the dependency is used. If you do not do manual upgrades but automatically update everything all the time bugs can sneak in and it won't always be easy to track down what caused it.
- dionian 9y ago
  in my experience traceability of the versions of the dependencies used is as important as tracing that you use them... having that all in source control and being to replicate an immutable build from that tag at any time in the future is useful especially for large and complicated projects.
zellyn 9y ago
Well, if each of those 1,000 dependencies goes three years between accidental breaking changes, you still have a broken build every day on average…
erik_seaberg 9y ago
Perpetually-stale is just a pejorative way of saying known-good. You should update frequently, but only when you have time to test for problems and when it's not an especially bad day to cause an outage for your clients.

snarfy 9y ago

If you've ever done web development and peeked into your node_modules folder you'll understand this is a serious problem.

KallDrexx 9y ago

> The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. I'd argue dependencies should be manually updated constantly. While version pinning does allow you to accrue technical debt if your team has discipline it does allow you to manage the upgrade process and understand the impacts of a dependency upgrade. Even without obvious API changes it's possible that the implementation details of a library's method can cause your code to function differently, which can be caused by the introduction of a bug, the fixing of a bug your code didn't realize was a bug, or any minor quirks that may change between versions. When you manually upgrade you know exactly what to test and what to look for because (presumably) the person doing the dependency upgrade is someone who knows how the dependency is used. If you do not do manual upgrades but automatically update everything all the time bugs can sneak in and it won't always be easy to track down what caused it.

dionian 9y ago
in my experience traceability of the versions of the dependencies used is as important as tracing that you use them... having that all in source control and being to replicate an immutable build from that tag at any time in the future is useful especially for large and complicated projects.

zellyn 9y ago

Well, if each of those 1,000 dependencies goes three years between accidental breaking changes, you still have a broken build every day on average…

erik_seaberg 9y ago

Perpetually-stale is just a pejorative way of saying known-good. You should update frequently, but only when you have time to test for problems and when it's not an especially bad day to cause an outage for your clients.