vstorm-co Assessing a dependency upgrade
Two questions: what breaks, and what happens if we do nothing.
Read in this order
The changelog between the two versions — every one, not just the latest · breaking changes and deprecations · security advisories fixed · whether the minimum runtime version moved · transitive dependency changes.
Classify
Security — has a deadline, and it is short. Breaking — needs code changes; list them with file paths. Routine — batch it.
Say what to test
Name the specific paths this dependency is on. "Run the suite" is not an assessment — the suite passing is necessary and, for a library that changes behaviour rather than signatures, not sufficient.
Always report the cost of waiting
Version drift compounds. Four majors behind is a project; one is an afternoon. Say which this is becoming.
Never
Upgrade a major version in the same change as a feature, or trust a green suite on a library whose defaults changed.