We had two major dependency-related crises with two different code bases (Android, and a Node.js web app). The Android repo needed to migrate from Flurry to Firebase, which required updating the Google Play Services library four major versions. A similar thing happened with our Heroku-hosted Node app where our production stack (cedar) was deprecated and needed to be upgraded to cedar-14. Our PostgreSQL database also needed to update from 9.2 to 9.6.
Each of these apps' dependencies sat stale for almost two years, and when some were deprecated and we reached the 'sunset' period, it has been a major headache to update them, or replace them. I've spent over 30 hours over the past month or two slowly resolving all of the conflicts and broken code.
Obviously letting things sit for two years is far too long. Technology moves quickly, especially when you're using a platform provider like Heroku. Let's assume that we have a full-fledged test suite, and a CI process like Travis CI, which takes a lot of the guesswork out of updating. E.g. if a function was removed after an upgrade, and you were using it, your tests would fail.
How often should dependencies be updated, or when should dependencies be updated? We updated because we were forced to, but it seems that some kind of pre-emptive approach would be better. Should we update when minor versions are released? Major versions? Every month if updates are available? I want to avoid a situation like what I just experienced at all costs.
PS - for one of my personal Rails projects, I use a service called Gemnasium which tracks your dependencies so that you can be notified of e.g. security vulnerabilities. It's a great service, but we would have to manually check dependencies for the projects I mentioned.