semver

Original：🇺🇸 English
Translated

Semantic versioning guidelines for software releases. Use when assigning version numbers, deciding between major/minor/patch bumps, managing unstable (0.x.x) software versions, evaluating breaking changes, or reviewing changelogs and release notes for correct semver compliance.

1installs
Sourcestuckinforloop/harness
Added on

NPX Install

npx skill4agent add stuckinforloop/harness semver

Tags

Translated version includes tags in frontmatter
semantic-versioningversion-bumpingbreaking-changesrelease-managementsemver-compliance

SKILL.md Content

View Translation Comparison →

Semantic Versioning

Version numbers follow the format Major.Minor.Patch (e.g., 
1.14.10
).

Stable Software (1.0.0+)

Change typeBumpResetExample
Breaking changeMajorMinor and Patch to 0
1.14.10
-> 
2.0.0
New feature or backwards-compatible behavior changeMinorPatch to 0
1.14.10
-> 
1.15.0
Bug fix or security fix (backwards-compatible)PatchNothing
1.14.10
-> 
1.14.11
Reserve patch releases exclusively for fixes. Lack-of-feature is not a bug — use minor releases for those.
Consumer guarantee: newer releases within the same major version are safe to upgrade to.

Unstable Software (0.x.x)

Software with major version 
0
is unstable — no stability commitment yet.
Change typeBumpExample
Bug fix or security fixPatch
0.3.2
-> 
0.3.3
Everything else (features AND breaking changes)Minor
0.3.2
-> 
0.4.0
  • Start development at 
    0.1.0
    .
  • Release 
    1.0.0
    when ready to commit to stability.
Consumer guarantee: fixes available within the same minor version.

Breaking Changes

Semver communicates breaking changes clearly — but does not make them cheap. For popular software with many downstream consumers, partial upgrades create ecosystem fragmentation.
Guidelines:
  • Avoid major version bumps for as long as possible.
  • If a major bump is unavoidable, provide a gradual migration path.
  • Do not treat semver as a license to make breaking changes.