The Big Yanking: Why I'm Removing Bogus Package Versions, and You Probably Should Too

As an open-source maintainer, I publish a lot of packages—sometimes daily. But let’s be honest: not every version is a masterpiece. Some are more like… a cursed artifact from a weekend hackathon. You know the type: it works on my machine, breaks on yours, and mysteriously installs fine on your coworker’s toaster.

Maybe I forgot to push a file. Maybe I shipped something I only tested in dev mode. Maybe the gemspec says it works on Ruby 2.7, but the syntax screams 3.3. Either way, it ends up blowing up on someone else’s machine like a bad dependency version of Russian roulette.

So here’s what I’m doing about it: I’m yanking those versions.

Yanking Isn’t Deleting History—It’s Taking Out the Trash

Some folks get nervous when you talk about yanking. “But what about historical accuracy?”

Yeah, no. This isn’t a museum. Broken code isn’t heritage—it’s hazardous waste.

You don’t slap a “legacy flavor” label on expired yogurt and call it artisanal. You throw it in the bin. That’s what I’m doing with broken versions: they go to version heaven (a.k.a. GitHub), but not to the public registry.

Because I’d rather Copilot complain that a version is missing than have it happily scaffold a production app on top of version 1.20.1, which, let’s face it, was one puts away from crashing in production.

Case Study: The Accidental Banana Peel

Let’s say I ship version 1.8.3 and forget to include a critical migration file. Someone installs it, hits a fatal error, and assumes my library is haunted.

I fix it in 1.8.4. Great. Now I’ve got two options:

1. Leave 1.8.3 online forever like a booby trap in a dependency jungle.
2. Yank it and pretend it never happened, like an adult who deletes their high school blog.

Spoiler: I chose #2.

Mistakes Happen. Cleanup Matters.

In open-source, the dev, QA, and release manager are often the same unpaid intern: you. So yeah, sometimes you hit publish too fast. It happens.

What matters isn’t perfection—it’s the cleanup.

By yanking broken versions, you:

• Protect future devs from stepping on your rakes
• Prevent broken versions from becoming AI-recommended “best practices”
• Avoid questions like “why does 1.6.0 remove half the methods from 1.5.2?”

And yes, someone will still ask you that on a GitHub issue from 2018.

My New Policy

So here’s what I’m doing moving forward:

If a version is broken, unsafe, incomplete, or just plain cursed, I’m yanking it.

You can still find it in Git history, along with my early attempts at naming things and the commit message “fix stuff lol.” But it won’t live in the registry. Because nobody needs to install a digital banana peel by mistake.

Open source doesn’t need more haunted versions. It needs maintainers who clean up after the party.

Yank It or Keep It? A Maintainer’s Checklist

If you’re wondering whether a version deserves to live, ask yourself:

✅ Yank These:

• Did I forget to push a file that makes it work? → Yank it. It’s not a version, it’s a trap.

• Did it work only on my machine and explode elsewhere? → Yank it. Congratulations, you built a landmine.

• Does the gemspec claim compatibility it doesn’t actually have? → Yank it. Lying about runtime versions is not a vibe.

• Did I push a quick fix right after (like 1.8.3, then 1.8.4)? → Yank the first one. Don’t make users guess which is edible.

• Was this version published past midnight and described as “should be fine”? → Yank it immediately. Nothing good happens after 2 a.m.

🚫 Maybe Don’t Yank These:

• Is it a minor bug that people have already worked around? → Maybe don’t yank it—just deprecate with a warning.

• Is someone depending on it and you just don’t like it anymore? → Leave it alone. This is cleanup, not a breakup.

The goal isn’t to have a perfect version history. It’s to have a usable one. And sometimes, that means admitting a version was a mistake and cleaning up the mess.

Your future users will thank you. Your past self might cringe a little, but that’s what growth looks like in open source.