Block the merge on warnings that name a removal date inside your next two releases, a security reason, or an API on a critical path. Ticket the rest with an owner and a date. Ignore only warnings you have judged and recorded as out of scope.
What a deprecation warning actually says
A deprecation is a vendor telling you that something will go away or has a better replacement. It does not tell you when. Some vendors attach a version or a date. Others do not. Under semantic versioning, a removal is a breaking change, so it belongs in a major release, which gives you a planning signal: a deprecated item in a 2.x SDK is likely gone in 3.0.
An SDK upgrade often turns a quiet warning into a build log full of them. Teams then tune out the noise, and the one that mattered scrolls past.
A triage rule
| Warning type | Action |
|---|---|
| States removal in a version or date within two releases | Block merge until a migration is planned and dated |
| Marked for security reasons | Block merge, treat as a vulnerability |
| API sits on login, payment or data handling path | Block merge, test the replacement |
| Removal later, replacement available | Ticket with owner and date |
| Removal later, no replacement documented | Ticket, ask the vendor, note the risk |
| Warning in code you do not ship | Record and move on |
The two release horizon is a choice, not a standard. Pick a number that matches your release pace and write it down.
How to surface them
- Make the build print deprecation warnings in full for your own code, instead of summarising them.
- Capture the warning list as a CI artifact for each upgrade pull request.
- Diff the list against the base branch. New warnings are the review target.
- Count and track the total over time. A rising number is a leading indicator.
- For JavaScript runtimes, the Node documentation describes flags that control how deprecations are reported, see our explainer on Node deprecation flags.
Warnings the SDK emits at runtime
Some SDKs log a deprecation notice when called in a certain way. Check the logs of a test run through your main flows, since these never appear at compile time. For a longer view, see how to see deprecation warnings before a major upgrade.
Keep a deprecation tracker
A shared list with the SDK, the deprecated item, the vendor's stated timeline, your owner and your target date keeps this from becoming memory. Our guide to building a deprecation tracker shows a layout.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings change over time, the same way a deprecation list should be tracked from one release to the next.
Where Safeguard fits
Safeguard's dependency scanning and policies can flag packages that carry a deprecation or advisory, and its SBOM output gives the baseline to compare against. A free scan is at gold.safeguard.sh/scan.
Quick check
Should every deprecation warning be fixed before merging?
No. Use a triage rule. Block on near term removals, security reasons and critical paths, and ticket the rest.
How do I know when a deprecated item will be removed?
Read the vendor changelog and policy. Semantic versioning puts removals in a major release, but the date is the vendor's to state, so ask if it is missing.
Last reviewed: 19 October 2026.
