Dependency upgrade risk assessment

Dig the breaking changes you will actually hit out of the changelog

I want to move [dependency] from [current version] to [target version]; the project calls it in roughly [N] places. Please: 1) list every breaking change between the two versions that could affect me, keeping only the ones my calls actually reach; 2) sort them into 'must change / should change / can leave', with the edit for each; 3) give the upgrade order (which one goes first, whether to split it into two steps); 4) name the problems most likely to surface only at runtime, and how to catch them locally first.

[paste the changelog and dependency config]

How to use

Paste the changelog text itself, not just the version numbers — without it, the model invents changes that never happened.

Good for

A major-version jump (React 17 to 18, webpack 4 to 5, Spring Boot 2 to 3) where the changelog is too long for anyone to finish.
A security advisory sets a deadline and you need a work estimate before someone runs npm update.

Not for

It is a patch bump (1.4.2 to 1.4.3) with no breaking changes in the changelog: upgrade and run the tests.
The package is only in devDependencies or used at build time: zero runtime risk, so do not assess it like production.

Example

Input

"react": "17.0.2" -> "18.2.0"

Call sites: 46 ReactDOM.render calls, all in 2 entry files; 3 class components use componentWillReceiveProps; tests depend on enzyme.
Changelog: automatic batching, effects double-invoked under StrictMode, ReactDOM.render deprecated, componentWillReceiveProps removed.

What you get

Classify the 46 ReactDOM.render calls and the 3 componentWillReceiveProps uses as must-change, noting that the render calls collapse into createRoot at two entry points; put the enzyme adapter under should-change; mark automatic batching's effect on render counts as runtime-only and warn that tests asserting render counts will fail. Order: test environment first, then entry files.

Common mistakes

Pasting the changelog without your call sites or usage: every breaking change gets counted as your workload.
Upgrading six packages at once, so when something breaks you cannot bisect the cause.

Try tweaking it like this

Include the real count from `grep -rn "ReactDOM.render" src | wc -l` and the files involved; the categories move from 'may affect' to 'must change'.
Add 'give me one local verification script I can run in a single pass' and the assessment becomes executable steps.