Repository metrics

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.

Methodology v1.13.0Updated 2026-07-13

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 (40% within category)
  • Weight in overall index: 8.8%
  • Metric key: release_discipline

How the value is computed

ComponentWeightCriteria
Ships releases27any published releases; same condition as v0.9.0, scaled to 27 points
Release recency36same thresholds as v0.9.0, scaled to 36 points
Release cadence27same thresholds as v0.9.0, scaled to 27 points
OpenSSF Scorecard: Signed-Releases10Scorecard's 0–10 result, scaled to 10 points

When release data is unavailable the metric is null — excluded from 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 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.

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 · package maintenance