How to track breaking changes and deprecations in your dependencies

What Dependabot covers and what it doesn't

Dependabot alerts flag dependencies that match a known advisory in the GitHub Advisory Database. Dependabot security and version updates open pull requests that move you to newer releases. None of them read deprecation notices: a request to warn about deprecated npm packages was opened in 2018 and closed as not planned (dependabot-core issue 2239).

The one place Dependabot shows you a breaking change is a major-version PR. Those PRs often include the package's release notes, so read them there before you merge.

Where breaking changes are announced

Package registries

• npm: a maintainer runs npm deprecate on a version or a range, and npm prints the message as a warning on every install (npm docs). The install still succeeds, so the warning is easy to miss. npm outdated (npm docs) shows a latest version beyond your range when a new major is out.
• PyPI: installers skip a yanked release unless it is pinned with == or listed in a lock file (PEP 592). Pinned projects keep installing it, with a warning at most.
• crates.io and RubyGems: cargo yank stops new lockfiles from picking a version while existing Cargo.lock files keep working (Cargo docs). gem yank removes the version from the index (RubyGems docs), so a fresh bundle install that needs it fails.

Release notes and changelogs

• Under semantic versioning, breaking changes go in a major version. Below 1.0, the spec allows anything to change at any time, so treat a 0.x minor bump like a major one.
• Every GitHub repository has a release feed at github.com/OWNER/REPO/releases.atom. For notifications instead, use the Watch menu: Custom, then Releases (GitHub docs).
• When you skip versions, read the changelog for every release in between. A removal in 4.0 may have been announced as a deprecation in 3.2.

API providers

• Many providers email deprecation notices to the account owner. Make sure that address is a shared inbox someone reads.
• Pin the API version where you can. GitHub's REST API reads an X-GitHub-Api-Version header; requests without it get 2022-11-28, supported until March 10, 2028 (GitHub docs). Stripe recommends setting Stripe-Version on each request rather than relying on the account default (Stripe docs).
• Log two response headers. Deprecation (RFC 9745) gives the date a resource was or will be deprecated. Sunset (RFC 8594) gives the date it is expected to stop responding.
• OpenAPI specs mark operations, parameters and schemas with deprecated: true. If a provider publishes its spec, diff each new version with the open-source tool oasdiff, whose breaking command lists changes that break existing clients.

Cloud runtimes

AWS gives at least 180 days' notice before a Lambda runtime is deprecated. It emails the account's primary contact and posts to the Health Dashboard when functions in the account use the runtime (AWS runtime policy). Both list only each function's $LATEST version. At the deprecation date AWS may stop patching the runtime and ends technical support for it. Blocks on creating, then updating, functions follow later. Existing functions keep running.

• Amazon Linux 2 reached end of life on June 30, 2026. Runtimes built on it, such as python3.10 and python3.11, now get operating system fixes only for critical and selected important security issues.
• Functions deployed as container images get no deprecation notices. You track the base image's dates yourself.
• Other services, such as RDS for MySQL and EKS, announce version end of support as AWS Health planned lifecycle events. AWS aims for at least 180 days' notice on major changes where possible (AWS Health docs).

Languages and frameworks

endoflife.date lists end-of-life dates for languages, frameworks and databases, with a calendar feed for each product. It lists October 31, 2026 as the end of security support for Python 3.10 (Python) and April 30, 2027 for Node.js 22 (Node.js).

A routine to catch them

Set up the first four items once. The last two are habits: one for each major-version PR, one for each week.

1. Make CI show deprecation warnings. Fail or annotate the build when install output contains npm warn deprecated (older npm versions print it in capitals). In Python, add error::DeprecationWarning to pytest's filterwarnings setting so deprecated calls fail the tests, then add ignore lines for third-party warnings you accept (pytest docs). On GitHub Actions, read the warning annotations on each run's summary. Runs with actions that still targeted Node.js 20 showed such warnings before GitHub removed Node 20 from its runners on September 23, 2026 (GitHub changelog).
2. List the runtimes you deploy. Run aws lambda list-functions in each Region you use and read each function's Runtime field. Functions built from container images have none, so note their base image instead (AWS). Add the rest of your stack: Node.js or Python in containers, database engine versions, Kubernetes. Put each end-of-life date in the team calendar with a reminder 90 days before (our suggested window), or subscribe to the endoflife.date calendar feed for each product.
3. Subscribe to release feeds for the 10 or so dependencies (our suggestion) whose breaking changes would cost you the most work, such as your framework, ORM, auth library and cloud SDK. Add the changelogs of the APIs you call. A feed reader or a Slack channel both work.
4. Send AWS Health events to Slack. Create an EventBridge rule that matches the source aws.health, target an SNS topic, and connect the topic to a channel with Amazon Q Developer in chat applications (AWS Health docs). One rule in US West (Oregon) receives account-specific events from all standard Regions (AWS). Also check that the account's primary contact email reaches someone who reads it.
5. Read the release notes before you merge a major-version Dependabot PR, including the notes for every version it skips. Passing CI shows your tests pass. It says nothing about behavior you don't test.
6. Once a week, review new CI warnings, end-of-life dates inside 90 days, new AWS Health events and provider emails. Bring anything with a date to your weekly operations review.

What to do when you find one

1. Check whether it affects you. Search the code and infrastructure files for the function, endpoint, option or runtime identifier, for example python3.10 in a SAM template.yaml, a serverless.yml or a Dockerfile. Then check whether tests cover that code path.
2. Find the date that matters. Plan against the date something stops working or stops getting fixes, not the announcement date. For a Lambda runtime, finish before the deprecation date, after which AWS may stop security patches. The block function update date is the last day you can deploy a code fix without also changing the runtime. For an API, use the Sunset date.
3. Give the work an owner and a due date. Leave room for one failed attempt before the hard date (our suggestion).
4. Make the change in a branch and let CI run. For Lambda, publish a new function version and point an alias at it, so rollback is one step; AWS recommends versions and aliases for this (AWS runtime policy).
5. If the release notes list changed defaults or behavior, ship the change behind a feature flag and watch error rates after the deploy.
6. Record the decision in your weekly log: what changed, the evidence link, the owner and the date. If you decide to stay on a deprecated version for now, write down a date to review that decision.

If an upgrade is big enough to be a project of its own, such as a major database engine version, compare a contractor with a hire in when to hire your first DevOps engineer.

Where Grant fits, and what he doesn't do

Since.dev records public changes from the sources it follows and publishes them on its Changes page with upstream evidence, labelled breaking, deprecated, behavioral, additive or advisory when the evidence supports it. On Grant's team, these AI specialists work from those records:

• David (compatibility and repairs) reports how recorded changes affect your connected repositories. For supported cases, such as a renamed symbol, Since.dev opens a repair pull request (a draft where GitHub allows it) and David points you to it. Repairs don't cover routine version bumps or lockfile changes, so keep Dependabot or Renovate for those.
• Owen (configuration and lifecycle) checks what your repository declares, not what is deployed, against recorded deprecations.
• Iris (World State) sets up watches on public pages, feeds and packages, and runs fact checks, only when you ask. For example, ask her to watch the Lambda runtimes page.

Check-ins run daily on Pro and every six hours on Studio, and David and Owen also check in on pushes. Grant answers in Slack, the dashboard and MCP. The team doesn't read AWS Health or your deployed Lambda settings, so keep the EventBridge rule.

Grant and his team are AI agents. Check-ins only read the sources you connect, except Vera's tests of your own agents. Repair PRs wait for your review, and nothing merges or deploys. Meet Grant and his team or read how to review a repair.

Questions

What's the difference between deprecated and end of life?

Deprecated means removal or loss of support has been announced, and the thing usually still works. End of life means support has ended: no more fixes or security patches, and it may stop working. For a Lambda runtime, deprecation is when AWS may stop patching it and technical support ends; existing functions keep running.

How much notice does AWS give before a Lambda runtime is deprecated?

At least 180 days, by email to the account's primary contact and in the Health Dashboard, for accounts with functions on that runtime. Creating functions is blocked at least 30 days after deprecation and updating them at least 60 days after, with later dates for some runtimes. Container image functions get no notice.

Does Dependabot open pull requests for major versions?

Yes, when version updates are on. To skip majors, add an ignore rule to dependabot.yml with dependency-name "*" and update-types "version-update:semver-major". The rule doesn't affect security updates. If you let majors through, read the release notes before merging.

Related guides

• How to triage Dependabot, code scanning and Security Hub alertsA 20-minute weekly routine to triage Dependabot, code scanning and AWS Security Hub alerts: known exploitation first, then exposure, then severity.
• Weekly operations review: a template for small software teamsA 30-minute weekly operations review for small software teams: the agenda, the checks for CI, AWS, security and dependencies, and a decision log to copy.
• DevOps for startups without a DevOps teamSet up four things once, then check five every week. A practical DevOps checklist for startups on GitHub and AWS that have no DevOps engineer yet.