Dependency upgrade assessment

Read every changelog between the current and target versions, not just the latest. Check breaking changes, deprecations, security advisories, minimum runtime version moves, and transitive dependency changes, then classify the upgrade as security, breaking, or routine.

Name the specific code paths the dependency is on and test those directly. A passing suite is necessary but not sufficient for libraries that change behavior rather than signatures, since existing tests may not exercise the changed defaults.

No. Never combine a major version upgrade with a feature in the same change. Mixing the two makes it impossible to attribute failures and complicates rollbacks when something breaks.

Version drift compounds over time. Being one major version behind is an afternoon of work, while four majors behind becomes a project, so the assessment should always state which situation the delay is creating.

A green suite is not proof of safety when a library changes behavior or defaults rather than signatures. Existing tests may not cover the affected paths, which is why the assessment names specific paths to verify instead of trusting the suite.