Plumb

Abandoned or archived

Checks whether the maintainer has marked the package abandoned on Packagist or archived its repository.
category
maintenance
weight
10
veto
when it fails, every category score is set to 0/100

How Plumb checks this

What is inspected, and how the result is decided.

A maintainer can tell the world that a package will not receive further fixes in two places: by marking it abandoned on Packagist, optionally naming a replacement, or by archiving the repository on the source host. Either one is the maintainer's own statement that future fixes will not come. That is the strongest warning a package can carry short of being malicious, and no amount of recent activity elsewhere changes it.

Plumb reads the abandoned flag from Packagist and the archived flag from the repository. Maintainers often set one without the other, so either one alone is enough. For a package that is not listed on public Packagist, the archived flag is the only signal available.

The check passes when neither flag is set and fails when either is. Failing sets every category score and the composite score to 0. When Packagist already carries the abandoned flag, the scan stops at this check, because nothing the other checks measure could change the outcome. When the maintainer named a replacement package, it is included in the evidence so the package page, the API, and the Composer plugin can point people to it.

This is a veto check. When it fails, every category score is set to 0/100 no matter how the other checks do. Learn how vetoes work.

Doing it well

Why this matters

Every package eventually reaches a point where its maintainer moves on. That is normal. What matters is whether the people depending on it find out. A package that is quietly abandoned keeps getting installed for years, with nobody left to fix the next vulnerability. A package that is clearly marked abandoned, ideally with a suggested replacement, lets its users plan a migration on their own schedule.

If your package is abandoned, marking it so is the responsible thing to do. If it is not abandoned, make sure it is not marked as if it were. Both Packagist and the repository host carry a flag, and either can be set by accident or left behind after a change of plans.

What good looks like

  • An actively maintained package is not marked abandoned on Packagist and its repository is not archived.
  • A package that is no longer maintained is marked abandoned on Packagist, names a replacement when one exists, and has an archived repository, so the message is the same everywhere users look.

How to do it

If you still maintain the package

Check both places:

  1. On Packagist, open your package page. If it shows "This package is abandoned", log in and clear the flag from the package's edit page.
  2. On GitHub or GitLab, open the repository settings. If the repository is archived, unarchive it. Archiving makes a repository read-only, so it also blocks pull requests and issues.

If you are handing the package over

Transfer the repository and the Packagist package to the new maintainer rather than abandoning them. On Packagist, add the new maintainer from the package page and let them remove you afterwards. On GitHub or GitLab, transfer the repository so the old URL redirects. Users keep working without any change.

If the package is truly finished

  1. Release any pending fixes first, so the last version is the best version.
  2. On Packagist, mark the package abandoned and enter the replacement package name if there is one. Composer shows it to anyone who installs or updates the package.
  3. Write a short note at the top of the README saying the package is no longer maintained and what to use instead.
  4. Archive the repository on the source host.

Things to watch for

  • Marking one place but not the other. Users and tools check both. An archived repository with a live Packagist entry, or the reverse, sends a mixed message.
  • Archiving to stop notifications. Archiving means "this is over". If you only want fewer notifications, change your notification settings instead.
  • Renaming without a pointer. If you moved the package to a new name, mark the old name abandoned with the new name as its replacement.
  • A replacement that does not exist yet. Only name a replacement that is published and installable.

Further reading