A policy I favor with dependency management: go forward. Going backward is an exception that we must plan to remedy.
Example
Consider a CVE in a dependency at version 5.0 (v5.0). We’re advised that v6.0 and v4.0 are safe. Which way should we go, forward or backward?
We want to default to forward. Even if we’ve been on v4.0 before and know it is compatible. Even if we aren’t sure that v6.0 is “solid” or if it takes some code changes to implement.
My reasoning here is that it puts it in a better place with OSS maintenance conventions. If another CVE is released, it’s likely to be found earlier in v6.0 and fixed there as well. Back-porting to v4.0 may not be prioritized.
There’s also nothing preventing another developer (or us) from making the upgrade to v6.0 tomorrow. Without a well-communicated, time-boxed exception, they won’t know that we chose to go backward, or why.
Conclusion
Go forward when you can. When you can’t, be intentional and communicative about why, and make sure you resolve the tech debt and potential dependency drift.
Note: I shared a version of this idea previously on Linkedin.