Deprecate, retract, unpublish, abandon, yank, orphan, archive...

What do all these have in common? Well, they’re different terms for what I’ll call “package invalidation.” Here’s what I mean by package invalidation: 

Package invalidation (n): the indication that an open source maintainer doesn’t want you to use their package or release(s). 

Do all package managers support invalidation?

Some programming language ecosystems have built-in tooling for invalidation, and some purposely don’t allow it, but one thing certainly holds true: none are the same. 

 You can view package invalidation support in two dimensions:

• Package-level vs. release-level: either the full package is invalidated, or just specific releases (i.e. versions).
• Deletion vs. deprecation: either the package is totally unavailable/gone/404’ed, or it is just marked as deprecated (i.e. a soft warning to not use the package).

Note that “code deprecation” is a separate topic. 

Why would you invalidate a package?

Maintainers will invalidate their packages for a range of reasons:

• the maintainers are stepping away
• it’s vulnerable to a bug or has malicious code
• it’s being renamed or moved
• there’s a better/faster alternative 
• secrets were accidentally published 
• it has a licensing issue

Are there problems with package invalidation support?

Yes 😬 ... package invalidation is a thorny and overlooked topic:

Firstly, every ecosystem implements invalidation differently. For example, the Maven package ecosystem for Java doesn’t allow removal of packages because it considers its package index immutable. Clojure, though—a language on the Java platform—follows suit but will make exceptions for security’s sake and is considering a more nuanced approach. When you’re in a polyglot environment, recalling the differences among ecosystems will be arduous.

Another problem is that it’s often difficult to know when a package/release that you use is invalidated, unless it’s outright deleted (which might be too late for your CI builds). For example, even though RubyGems allows the removal of a specific release by the maintainer, you may never know if you are using cached versions of that release.

Lastly, a big problem we found is that maintainers often don’t use the built-in tooling. Sometimes package invalidation is just a note in the README (maybe a “DEPRECATED” note or a badge from unmaintained.tech). This makes it even trickier to be warned against using a package.

Matrix of support

Because this subject can be so complex and confusing, we have compiled a matrix of invalidation support for you to use as reference. 

Other questions to consider

There are some other details that will determine how invalidation works, too. Can an invalidated package be aliased or redirected to another package? How are name handoffs or disputes handled? Can deleted releases be re-published?

How the Tidelift Subscription can help

It can be very tricky to learn about deprecated packages and to navigate each ecosystem’s support, even if you’re paying attention. So how would you be alerted to and/or act upon an invalidated package?

Tidelift catalogs can help: catalogs provide a birds-eye view of all the open source packages that your organization is using. Catalogs have a “Releases are actively maintained” standard that you can enable and enforce. 

When enabled, it will let you know when a deprecated package is in use and lets you block it from all your projects. We pull this data via the official tooling from each ecosystem as best we can, so you don’t have to worry about all these details.

And by paying for the Tidelift Subscription, you’re also paying the maintainers. The maintainers know best whether a package has been invalidated, and we work closely with the maintainers to bring that information directly to you via the Tidelift Subscription. Curious how that works? You can watch a short demo, or, better yet, schedule a custom demo and one of our team members will show you how Tidelift catalogs work.