Plumb

Commit and release recency

Checks when the package last had a commit on its default branch or a stable release.
category
maintenance
weight
5

How Plumb checks this

What is inspected, and how the result is decided.

A package that has not changed in a long time may simply be finished, but it may also be quietly abandoned. Recency alone cannot tell the two apart, which is why this check carries a modest weight. Combined with the other maintenance signals it is a useful early warning: a package with no recent commits and no recent releases is unlikely to receive a fix when one is needed.

Plumb reads two dates: the most recent commit on the repository's default branch, and the publication date of the most recent stable release on Packagist. Either one being recent is enough, so a stable package that ships a release without many commits, or one that commits steadily between releases, is treated fairly.

The check passes when the latest commit is 90 days old or less, or the latest stable release is 180 days old or less. The 90-day commit window follows the OpenSSF Scorecard Maintained check. It fails when both signals have been silent for more than a year. Anything in between warns with half credit. When neither date can be determined the check is unassessable.

Doing it well

Why this matters

A package that has not seen a commit or a release in a long time raises a fair question: if a security problem is found tomorrow, will anyone fix it? Sometimes the answer is yes and the package is simply stable. Users cannot tell the difference from the outside, so visible activity is how a maintainer shows the package is still in good hands.

This is not about churning out commits. It is about leaving evidence, a few times a year, that someone is paying attention.

What good looks like

  • A commit on the default branch within the last three months, or a stable release within the last six months.
  • Small, regular signs of life rather than long silences followed by big catch-up work.

How to do it

Release what you have

If there are merged changes on your default branch that were never tagged, tag a release. Users cannot install commits; they install tags. A release is also the clearest sign of life a package can give.

Keep dependencies current

Running an update bot such as Dependabot or Renovate, and merging its pull requests, produces steady and useful activity with little effort. It also keeps the package installable on current PHP and framework versions.

Do the small maintenance tasks

  • Add the newest PHP version to your CI matrix and your composer.json constraint when it is released.
  • Fix a typo in the docs, close stale issues, refresh the README. Each is a commit.
  • Widen the version constraint on a framework you support when a new major comes out.

Stable does not mean silent

If the package is complete and needs no new features, say so in the README, for example "This package is feature complete; releases will be maintenance only". Then still merge dependency updates and CI fixes so the evidence of attention remains.

If you are done, say so

If you no longer intend to maintain the package, marking it abandoned on Packagist is more honest than letting it drift. It tells users to plan a migration instead of guessing.

Things to watch for

  • Work on a branch that never reaches the default branch. Activity on a feature branch does not show up as activity on the package.
  • Commits without releases for a year or more. People installing through Composer are still getting the old code. Tag a release.
  • Pre-releases only. Alpha and beta tags are useful, but a stable release is what most users can actually adopt.
  • Changing the default branch without updating Packagist. Packagist follows the branch your repository declares as default. Make sure that is the branch you commit to.

Further reading