# Package maintenance

> How inspect.software measures registry upkeep — publish recency, version history, and deprecation state of published packages. 4.8% of the overall index.


**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](/wiki/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](/wiki/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](/wiki/supported-ecosystems) for the matching rule.
- Non-publishing repositories are `null` here 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](/wiki/ecosystem-adoption) ·
[release discipline](/wiki/release-discipline)