Bumpy: put release decisions where reviewers can see them

Releasing a collection of packages can become a surprisingly human process. Someone remembers which package changed, someone else works out whether it needs a patch or minor bump, and release day turns into detective work. Bumpy puts those decisions in the pull request instead. It is not a new idea from nowhere; it is a newer take on the file-based workflow that Changesets made familiar.

A small file with a useful job

When a change deserves a release, a contributor adds a Markdown “bump file” under .bumpy/. The file names the affected packages, marks each as patch, minor or major, and carries a short changelog note. Reviewers can argue about the release impact while they are already looking at the code. Once changes merge, CI gathers those files into a release proposal, updates versions and changelogs, and publishes according to the project’s configuration.

That is the practical payoff: release intent becomes a reviewable piece of the change, not an oral tradition held by the one person who usually presses Publish. It also gives new maintainers a trail they can understand later.

What makes Bumpy worth a look?

The interesting parts are in the awkward corners of a monorepo. Bumpy supports workspace and catalog dependency references across npm, pnpm, Yarn and Bun. It offers configurable dependency propagation, so a change to one package can update dependent packages according to rules the team has chosen. It also allows per-package publish commands. That matters if your “packages” include a VS Code extension, a Docker image or a JSR release alongside npm modules.

Its CI path uses bumpy ci check and bumpy ci release in an ordinary GitHub Actions workflow. Bumpy also has branch-based prerelease channels that derive prerelease versions at publish time rather than committing them to Git. These are concrete reasons to examine it if your current release process needs special targets or frequent prereleases.

There is an agent skill for creating bump files too. That may save typing, but I would still want a human reviewer to check the proposed version level and changelog. Automation can carry a decision; it cannot make that decision unimportant.

Do you need to switch from Changesets?

Probably not just because a newer tool exists. Changesets v3 has addressed many older complaints. Bumpy’s own comparison acknowledges that cleanup. The case for switching is stronger if you need its particular propagation controls, catalog handling, custom publishing or prerelease model. InfoQ also reports a migration issue involving Yarn 4.10 catalog detection, so “automatic migration” should be treated as a starting point, not a guarantee.

For a real evaluation, take a representative branch in a disposable copy of your monorepo. Add a patch to one library and a breaking change to another. Check the generated versions, dependent-package bumps and changelog text. Run a prerelease branch, then rehearse each non-npm publishing target without actually shipping it. Compare the result against your current Changesets v3 workflow before moving release credentials or changing CI.

The skill worth learning is bigger than Bumpy itself: model your package dependency graph, decide release policy in code review, and make CI produce a release you can explain. If Bumpy handles your rough edges, lovely. If your current setup already does that reliably, you may have learned enough without migrating.