Package maintenance checks that a project's published package is current, resolvable, and not deprecated on its registry. Registry upkeep is distinct from GitHub activity: a library can go stale — or be explicitly marked abandoned — on npm or Packagist while its repository still sees commits, and users install the package, not the repository.
- Category: Sustainability & Governance (20% within category)
- Weight in overall index: 4.8%
- Metric key:
package_maintenance - Applies to: repositories that publish at least one package; otherwise
null
How the value is computed
| Component | Weight | Criteria |
|---|---|---|
| Published & resolvable | 25 | at least one of the repository's packages resolves on its registry |
| Publish recency | 35 | latest publish ≤180 days → 35 pts, ≤365 → 26, ≤730 → 14, older → 4 |
| Version history | 20 | ≥5 published versions → 20, ≥2 → 12, otherwise 4 |
| Not deprecated | 20 | deprecated (npm), abandoned (Packagist), or yanked latest → 0; otherwise 20 |
Why each component matters
- Resolvable is the baseline: the package installs from the registry a user would actually reach for.
- Publish recency catches the silent failure where fixes land in the repository but never ship — the registry copy quietly ages while the repository looks alive.
- Version history distinguishes a maintained release line from a one-shot publish.
- Deprecation is the registry's own strongest signal, set by the maintainers themselves; a deprecated latest version zeroes the component outright.
Reading the result
- Cross-read with release discipline: GitHub releases and registry publishes usually move together, and divergence between them is itself informative.
- Only packages whose registry metadata verifiably points to the inspected repository are counted — see supported ecosystems for the matching rule.
- Non-publishing repositories are
nullhere and their category renormalizes — never a penalty for being an application.
Improving the value
- Publish releases to the registry as part of the release process, not as an afterthought.
- Keep at least a yearly publish cadence for maintained packages — even a patch release restores recency.
- Never leave a deprecated or yanked version as the latest; publish a successor or clear the flag.
Related: ecosystem adoption · release discipline