# Release discipline

> How inspect.software measures release discipline — whether versioned releases ship, how recently, and on what cadence. 8.8% of the overall health index.


**Release discipline** measures whether a project ships versioned releases —
the mechanism by which work in the repository actually reaches users.
Downstream consumers pin versions, read changelogs, and upgrade on release
boundaries; a project that never cuts releases forces every user onto
unversioned snapshots.

- **Category:** [Vitality](/wiki/vitality) (40% within category)
- **Weight in overall index:** 8.8%
- **Metric key:** `release_discipline`

## How the value is computed

| Component | Weight | Criteria |
| --------- | ------ | -------- |
| Ships releases | 27 | any published releases; same condition as v0.9.0, scaled to 27 points |
| Release recency | 36 | same thresholds as v0.9.0, scaled to 36 points |
| Release cadence | 27 | same thresholds as v0.9.0, scaled to 27 points |
| OpenSSF Scorecard: Signed-Releases | 10 | Scorecard's 0–10 result, scaled to 10 points |

When release data is unavailable the metric is `null` — excluded from
[Vitality](/wiki/vitality) with weights renormalized, never counted as zero.
The Scorecard component is likewise excluded when Scorecard is unavailable or
reports `n/a`; it remains a full Security signal as well.

## Why releases are measured separately from commits

Commit activity and shipping are different disciplines. A repository can show
constant motion on its default branch while users wait a year for a release
containing the fixes; the inverse — calm branches, punctual releases — also
exists. Splitting [development activity](/wiki/development-activity) from
release discipline makes both patterns visible instead of letting one hide
the other.

## Reading the result

- **Recency is the heaviest component.** A project with a strong release
  history that stopped releasing eighteen months ago reads materially lower
  than one that shipped last quarter.
- **Cadence rewards rhythm, not frequency for its own sake.** A steady
  quarterly cycle earns most of the cadence points; the top tier simply
  reflects the short iteration loops common in actively developed libraries.
- **GitHub releases are the source.** Projects that tag versions without
  publishing releases, or release only through a registry, may read lower
  here; registry publish recency is measured separately in
  [package maintenance](/wiki/package-maintenance).

## Improving the value

- Publish releases through the repository's release mechanism, not only as
  tags.
- Release on a predictable cadence — small, regular releases outscore rare
  large ones and serve users better for the same reason.
- After any dormant period, a single fresh release immediately restores the
  recency component.

Related: [development activity](/wiki/development-activity) ·
[package maintenance](/wiki/package-maintenance)