What breaks if you upgrade?
DepDelta answers that for any open-source package. It collects what changed between two versions, sorts it, and puts the breaking changes first.
Release notes, sorted
As published in Kotlin 2.3.0
On DepDelta
A project still set to 1.8 won't build after this. It goes to the top.
See the latest Kotlin release: 2.4.20 → 2.4.21Why it exists
An upgrade means reading GitHub Releases, changelog files, vendor notes, commit logs and security advisories, each in its own format. Breaking changes get missed, then turn up at build time or in production.
Where the data comes from
Package details come from the public registries:
Changes come from whatever each package publishes:
- Release notes
- Vendor pages like AndroidX, Kotlin and Spring, GitHub and GitLab Releases, and changelog files split by version.
- Commit log
- Every release between two tags, in its own tab. A package in a monorepo shows the commits in its folder.
- API signatures
- Read from what each package ships, like .d.ts files or JVM bytecode, in their own tab.
- Security and project health
- The GitHub Advisory Database and OSV, OpenSSF Scorecard results, and dependency graphs from deps.dev.
What you can rely on
- Every entry links to its source
- You can always check a line against where it came from.
- Summaries are marked
- They never pass as the maintainer's words, and any comparison can switch to the published text.
- Mistakes can be flagged
- Report an entry that looks wrong and it goes to the correction queue.
- No account needed
- Comparisons are free to read without signing in.
Who builds it
I'm Mbuodile Obiosio, a mostly self-taught developer whose curiosity and love of learning have led to more than a decade of building software. I work as an Infotainment Software Engineer at Volvo Group in Gothenburg, Sweden, a global leader in automotive safety. A company I'd dreamed of working for since I was a boy. Here's where I have really evolved, both as an engineer and as a person. Working here has shaped how I think, build and approach problems. Along the way, I've also mentored learners on the Android track of the Google Africa Developer Scholarship. Outside work, I run a homelab, write, take photographs and travel whenever I can.
DepDelta grew out of a frustration I kept returning to across different stacks: an upgrade that looks straightforward until you're deep in release notes, juggling tabs and wondering what you've missed. Conversations with other developers brought up the same frustration. I wanted a clearer way to understand what changed between two versions and what it meant for the code in front of me. Eventually, I started building the tool I kept wishing I had. DepDelta is that independent project, shaped by the work I do and the questions I ask when I'm the one facing an upgrade.
Get in touch
Found a bug, a wrong verdict or a missing package? Tell us what happens now and what you expected.