1. Even if you don't want to always use the latest dependencies, having the capability in reserve is important. When some emergency need pops up (e.g. massive security issue) you don't want to be trapped by a wall of your own making. So you'll at least need a pattern of prototyping and testing builds with newer dependencies, even if the builds aren't released. (Discover how to make your code forward-compatible before it becomes an emergency.)
2. As a general rule, newer means fewer security vulnerabilities, particularly if the project is careful about introducing new features versus bug-fixes. Not always, and maybe you don't want super-bleeding edge releases, but mostly.
3. I've worked in some areas with bureaucratic or governmental impediments, where you want to avoid things that might trigger re-testing or re-certification. That's a reason not to upgrade much, but it does mean you need to actually read the changelogs etc. and have some sort of process for noticing when something is important enough.
It depends how your product is distributed. Is it a static binary or a website where users don’t interact with the source code? Then dependency updates are less important.
Is it an open source package where every user inherits your dependencies? Then dependency updates are important.
The immediate benefits (or lack thereof) all come down to user impact. The longer term benefits are a balancing act between opportunity cost (what could you be developing instead of updating?) and tech debt (if you don’t update frequently, you’ll eventually need to do a really painful one).
I’d say the most important thing is making sure your project will build successfully in five years even if you do
no updates. Make sure all dependencies are cached, versions pinned, lockfiles used, etc. As long as your build process is deterministic, and you control when updates happen, then “when to update” is a manageable problem. You get into trouble when your tools are pulling in minor updates to dependencies just because the author pushed a new version. Don’t do that. Pin your versions.
Even if there's no "real" reason to upgrade them today, the longer you go between updates the larger and more difficult the task will be when you eventually can't ignore it any longer.
The discussion around operating system package updates is definitely important.
I’m also curious to hear how teams handle dependency updates in software development projects, things like versions listed in package.json, build.xml, or similar files. How do you decide when to update these kinds of dependencies, and how frequently do you do it?
We use Renovate to keep dependencies up-to-date across npm, Kotlin, Docker and GitHub Actions. It automatically monitors all the dependencies (including in our private repositories) and opens PRs (max 10 at a time) against those repos. This week I added grouping of related dependencies (e.g. all Spring boot dependencies or all ESLint dependencies).
Providing the pipeline is green, any minor, patch or image digest update can be merged automatically (with an approval coming from the renovate approve bot) and major updates need the approval of a developer.
If you accept that it's good to keep up with dependency versions, you only have a few options: update infrequently, update frequently, somewhere in-between. If you update infrequently, misbehaviour will be harder to track down to which dependency change causes it or if it's a combination. This is why frequent/regular dependency updates are good.
It's similar logic to why continuous deployment is better than releases a few times a year.
I like to use LTS distros and check dependencies every six months. I don't think it adds value, fundamentally it's revisiting stable code to change something that is working so it introduces a risk, but it prevents having to deal with an accumulation of changes all at once which can introduce incompatibilities and other dependency issues.
Part of the value of the product that I work on is not introducing security vulnerabilities to our clients. That means keeping things like openssl up to date. We did find a vulnerability in a penetration test as a result of not keeping openssl up to date.
Otherwise, compiler upgrades have improved our runtime and prevented errors (which in our case typically result in the user experiencing a 500), and database upgrades have improved query performance.
1. Even if you don't want to always use the latest dependencies, having the capability in reserve is important. When some emergency need pops up (e.g. massive security issue) you don't want to be trapped by a wall of your own making. So you'll at least need a pattern of prototyping and testing builds with newer dependencies, even if the builds aren't released. (Discover how to make your code forward-compatible before it becomes an emergency.)
2. As a general rule, newer means fewer security vulnerabilities, particularly if the project is careful about introducing new features versus bug-fixes. Not always, and maybe you don't want super-bleeding edge releases, but mostly.
3. I've worked in some areas with bureaucratic or governmental impediments, where you want to avoid things that might trigger re-testing or re-certification. That's a reason not to upgrade much, but it does mean you need to actually read the changelogs etc. and have some sort of process for noticing when something is important enough.
It depends how your product is distributed. Is it a static binary or a website where users don’t interact with the source code? Then dependency updates are less important.
Is it an open source package where every user inherits your dependencies? Then dependency updates are important.
The immediate benefits (or lack thereof) all come down to user impact. The longer term benefits are a balancing act between opportunity cost (what could you be developing instead of updating?) and tech debt (if you don’t update frequently, you’ll eventually need to do a really painful one).
I’d say the most important thing is making sure your project will build successfully in five years even if you do no updates. Make sure all dependencies are cached, versions pinned, lockfiles used, etc. As long as your build process is deterministic, and you control when updates happen, then “when to update” is a manageable problem. You get into trouble when your tools are pulling in minor updates to dependencies just because the author pushed a new version. Don’t do that. Pin your versions.
Being up to date allows you to be in a better position for unexpected change
Even if there's no "real" reason to upgrade them today, the longer you go between updates the larger and more difficult the task will be when you eventually can't ignore it any longer.
The discussion around operating system package updates is definitely important.
I’m also curious to hear how teams handle dependency updates in software development projects, things like versions listed in package.json, build.xml, or similar files. How do you decide when to update these kinds of dependencies, and how frequently do you do it?
We use Renovate to keep dependencies up-to-date across npm, Kotlin, Docker and GitHub Actions. It automatically monitors all the dependencies (including in our private repositories) and opens PRs (max 10 at a time) against those repos. This week I added grouping of related dependencies (e.g. all Spring boot dependencies or all ESLint dependencies).
Providing the pipeline is green, any minor, patch or image digest update can be merged automatically (with an approval coming from the renovate approve bot) and major updates need the approval of a developer.
If you accept that it's good to keep up with dependency versions, you only have a few options: update infrequently, update frequently, somewhere in-between. If you update infrequently, misbehaviour will be harder to track down to which dependency change causes it or if it's a combination. This is why frequent/regular dependency updates are good.
It's similar logic to why continuous deployment is better than releases a few times a year.
I like to use LTS distros and check dependencies every six months. I don't think it adds value, fundamentally it's revisiting stable code to change something that is working so it introduces a risk, but it prevents having to deal with an accumulation of changes all at once which can introduce incompatibilities and other dependency issues.
We attempt to update node dependencies on a weekly cadence, and LTS whenever it’s released.
IMO the sooner the better, lets us outline the maintenance work.
Part of the value of the product that I work on is not introducing security vulnerabilities to our clients. That means keeping things like openssl up to date. We did find a vulnerability in a penetration test as a result of not keeping openssl up to date.
Otherwise, compiler upgrades have improved our runtime and prevented errors (which in our case typically result in the user experiencing a 500), and database upgrades have improved query performance.
So, yes. Update your stuff.