dependency-upgrade-assessment

# 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.