Prompt · Developer Tools

Dependency Upgrade Plan

Plans a safe major-version upgrade: blast radius, codemods, and rollback.

Have ready: Name the dependency, current version, and target version

Fill in · 8 fields

NAMEX.Y.ZA.B.CNPM / PIP / CARGO / GO / ETC.WHICH FEATURES/APIS WE DEPEND ONROUGH COVERAGE OF THE TOUCHED AREAS, HONESTXA

Your prompt

Plan the upgrade of this dependency. Major versions break things, find where before it ships.

Dependency: [NAME]
Current version: [X.Y.Z] → Target: [A.B.C]
Ecosystem: [NPM / PIP / CARGO / GO / ETC.]
How we use it: [WHICH FEATURES/APIS WE DEPEND ON]
Test coverage: [ROUGH COVERAGE OF THE TOUCHED AREAS, HONEST]

Deliver:
1. Breaking changes between [X] and [A] that affect MY usage, quote the changelog entries and map each to my code.
2. Blast-radius map: every file/module that touches this dependency, and which ones are high-risk.
3. The upgrade sequence: pin, upgrade in a branch, codemods (write them if mechanical), deprecation shims for anything that can't move yet.
4. Verification plan: which tests to run, what to check manually, and the canary/monitoring for the first deploy.
5. Rollback plan if it breaks in production.
6. Anything I should NOT upgrade past, a version with known issues for my use case.

If the changelog is vague about a breaking change that touches my usage, say so and tell me how to test that specific behavior.

Plan the upgrade of this dependency. Major versions break things, find where before it ships.

Dependency: [NAME]
Current version: [X.Y.Z] → Target: [A.B.C]
Ecosystem: [NPM / PIP / CARGO / GO / ETC.]
How we use it: [WHICH FEATURES/APIS WE DEPEND ON]
Test coverage: [ROUGH COVERAGE OF THE TOUCHED AREAS, HONEST]

Deliver:
1. Breaking changes between [X] and [A] that affect MY usage, quote the changelog entries and map each to my code.
2. Blast-radius map: every file/module that touches this dependency, and which ones are high-risk.
3. The upgrade sequence: pin, upgrade in a branch, codemods (write them if mechanical), deprecation shims for anything that can't move yet.
4. Verification plan: which tests to run, what to check manually, and the canary/monitoring for the first deploy.
5. Rollback plan if it breaks in production.
6. Anything I should NOT upgrade past, a version with known issues for my use case.

If the changelog is vague about a breaking change that touches my usage, say so and tell me how to test that specific behavior.

Paste it into Muse or any assistant. Blank fields stay as [brackets].

More like this

Serialization Chooser

Query Plan Explainer