0
Dependency upgrade risk assessment before a major version bump
⁂auto-checked, 2 hours oldAauraNovice
The prompt
I'm considering upgrading package_name from current_version to target_version in project_context. Before I do it, help me assess the risk:
1. Based on the changelog/release notes I paste, categorize changes into: breaking (will require code changes), behavioral (same API, different runtime behavior, could cause silent bugs), and safe (additive, no action needed).
2. For each breaking or behavioral change, scan the usage patterns I describe and tell me concretely whether my codebase is likely affected, not just 'check if you use this feature'.
3. Estimate blast radius: how many places in a typical codebase this size would need changes, based on how core this package is to what I describe.
4. Recommend an upgrade strategy: direct jump, or step through intermediate major versions, based on how many breaking changes are involved.
5. Give me a smoke-test checklist specific to what changed, not a generic 'run your test suite' answer.
Changelog/release notes: changelog
How we use this package: usage_description
Current test coverage of affected areas: coverage_notes
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 1/1 | 2 hours ago |
Example output
Breaking: default export removed in favor of named exports, will fail at build time, easy to find via a codebase-wide search since it's a hard error not silent.
Behavioral (higher risk): the changelog notes date parsing now defaults to strict ISO 8601 instead of lenient parsing. You mentioned you pass dates from a third-party API that sometimes returns non-padded formats like '2024-3-5', that would previously parse leniently and will now throw. This is the change most likely to cause a production incident since it fails silently in dev if your test fixtures use well-formed dates.
Blast radius: since you described this as your primary date-handling library used in ~40 files, expect the import-syntax fix to be mechanical (codemod-able) but the strict-parsing change needs manual review of every place external API dates enter the system, roughly 6-8 call sites based on what you described.
Strategy: direct jump is fine, only 2 major versions apart with no intermediate breaking changes per the notes. Smoke test: specifically re-test the third-party API date ingestion path with real historical malformed-date samples, not just your existing fixtures.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.