Dependency Update Strategies

Why are developers mindlessly upgrading major versions of dependencies and expecting everything to be okay?

Years? After one year, something amongst the hundreds of deps will have a horrible security vulnerability and updating means breaking changes.

Why do your dependencies break your project all the time that it needs updates itself?

Yeah, I mean what's the alternative? Your code will bit rot if you don't keep up. You don't have a living software project if you don't do this.You should read the release notes of the new version of your dependency, fix any obvious issues from that, see if your tests pass, and wait for bug reports to roll in for non-obvious things not caught by automated tests. Ideally you should do this before the new release of the dependency hits the repos of the distros most of your u

Update all your dependencies periodically - monthly, quarterly, whatever. Freeze dependencies in the meanwhile.

No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.

>frequently change without noticeUnless you are doing something so spectacularly, mind-blowingly irresponsible in your dependency management that changes just come in of their own accord (i.e. Go's defaults), no they don't. They change when you choose to vendor the new version or change the pinned version number.It's true that your dependencies won't get security updates until you decide to upgrade, but other people are certainly not writing security updates for your

You get more benefits from updating your dependencies than "just" bugfixes. There can be performance improvements or security updates in new releases. If you have a proper CI/CD pipeline and test environment(s) in place, it shouldn't be too much work. (Of course it highly depends on your domain.) Then the benefits clearly outweight the extra effort.

I don't think it's as simple as that.Some of the modern ecosystems have gone entirely bonkers (think nodejs/npm): hundreds and thousands of dependencies for the simplest of things, basically an unmanageable "supply chain".Sure, we can talk about what's good approach to update and dependency hygiene, how packages should "freeze" their dependencies, how should breaking changes be communicated through version numbers (or not), but we've seen the ri

Security/dependancy updates depend solely on the specific maintainers. The platform itself doesn't automatically fix the developer or maintainer lethargy in this regard.