3 ms·
> In this case, it doesn't matter to me which dependency update broke it, what matters to me is to have the tests passing again with all dependencies. Knowing
by strbean 5y ago
> In this case, it doesn't matter to me which dependency update broke it, what matters to me is to have the tests passing again with all dependencies.
Knowing which change (or changes) broke it can make resolving the issue much faster.
> If a version is done then why is there a new release? Using old versions is tech debt that will one day blow up and cost much more to correct than if it had been corrected over the time
Because <new feature> was added, that is totally irrelevant to your use case.
> not to mention the security risk.
As parent mentioned, there is automated tooling for this. Your tooling yells that you are using a version of a package with a vulnerability, so you update.
> Another dependency might decide to use that dependency in a newer version, in which case aren't we all better off using the latest versions of everything?
If you don't update A, it doesn't matter if a newer version of A wants a newer version of B.
> The cost is some effort, the benefit is more features, security, performance, less bugs, basically a better program.
This assumes bugs and vulnerabilities decrease monotonically over time. This isn't true.
> Then why upgrade at all when you have a dependency with a security issue? After all, in your upgrade you might be adding even more unknown security issues that might be even more dangerous.
Because a known (to the world) security flaw is orders of magnitude more dangerous than an unknown (to the world) one, all else being equal. If there is a CVE for it, there are likely large-scale attempts at exploiting it anywhere it can be found.
> If I can test well that a newer version of a dependency works for me, why not upgrade it? There might be performance, security or other bugfixes, and I'm allowing other maintainers of other dependencies to also use that newer version.
Large amounts of labor. Furthermore, "well-tested" may include "battle tested". Some bugs make it through to deployment, and get caught and fixed. Updating dependencies without a good reason means more potential bugs slipping through, which means more bugs being discovered in deployment and a worse experience for the end user.