Semantic Versioning 2.0.0¶
Preston-Werner, T. (2013). Semantic Versioning 2.0.0.
Cited by¶
21 citations across 21 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Change Notification
- In software, a platform announces that a method will be removed in a future version, giving dependents a window to migrate before the change binds.
This sourceSpecifies that a breaking (backward-incompatible) change to a public API MUST increment the MAJOR version, with deprecation announced in a prior release so dependents have a migration window before the change binds — the directed advance notice of a breaking change to a shared interface or schema.
SupportedVerified against the work's full text
SemVer FAQ says to announce a deprecation in at least one minor release before removing the functionality in a major release, so users can move to the new API.
“Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.”
- In software, a platform announces that a method will be removed in a future version, giving dependents a window to migrate before the change binds.
- Compatibility
- Software engineering: Binary compatibility (ABI stability), source compatibility (API contracts), version compatibility (semantic versioning, formalized by Preston-Werner (2013) as a contract for backward-compatibility communication), format compatibility (file formats, compression codecs), protocol compatibility (HTTP versions, messaging standards), hardware compatibility (processor instruction sets, memory requirements).
Supported in partVerified against the work's full text
The spec supports only the version-compatibility item: MAJOR.MINOR.PATCH numbers signal backward-compatible or breaking API changes; the other five compatibility types are not covered.
“Once you identify your public API, you communicate changes to it with specific increments to your version number.”
- Software engineering: Binary compatibility (ABI stability), source compatibility (API contracts), version compatibility (semantic versioning, formalized by Preston-Werner (2013) as a contract for backward-compatibility communication), format compatibility (file formats, compression codecs), protocol compatibility (HTTP versions, messaging standards), hardware compatibility (processor instruction sets, memory requirements).
- Incomplete Contract
- An API contract runs the identical three-knob design: the spec deliberately underspecifies behaviour under future feature requests (the gap), names a breaking-change committee plus an RFC process as the handler, and binds it with a published versioning policy and deprecation timeline as Governance — guarding against the analog of overreach, an unannounced breaking change that strands downstream consumers.
Supported in partVerified against the work's full text
SemVer supplies the published versioning policy and deprecation procedure (MAJOR for incompatible changes, a minor release carrying deprecation before removal); the committee, RFC and 'underspecified spec' parts are not in it.
“Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.”
- An API contract runs the identical three-knob design: the spec deliberately underspecifies behaviour under future feature requests (the gap), names a breaking-change committee plus an RFC process as the handler, and binds it with a published versioning policy and deprecation timeline as Governance — guarding against the analog of overreach, an unannounced breaking change that strands downstream consumers.
- Open-Closed Principle
- Platform and API design offers stable public contracts plus extensible endpoints, callback hooks, and plugin systems, letting vendors evolve a product without breaking customer integrations.
This sourceSpecifies that backward-incompatible changes to a public API MUST increment the MAJOR version — the elevated, ceremonialized gate distinguishing a breaking kernel/contract change from additive (minor/patch) extension, and the mechanism letting platforms evolve without breaking dependent integrations.
Supported in partVerified against the work's full text
SemVer supports the stable-public-API-with-compatible-additions part: backward-compatible additions are minor releases and consumers can upgrade without rebuilding dependents.
“Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API.”
- Platform and API design offers stable public contracts plus extensible endpoints, callback hooks, and plugin systems, letting vendors evolve a product without breaking customer integrations.
- Open Publication for Interoperability
- The published artifact is the library; addressability is the registry coordinate (a stable name-and-version handle) every dependent can reference; the open license is a permissive license file granting reuse and derivative rights without per-use permission; the re-use-ready form is a conventional package layout with a machine-readable manifest that build tooling consumes without bespoke translation; public access is the registry's open download with no paywall or membership gate; and the versioned commitment is semantic-versioning discipline, where breaking changes are signaled by a major-version bump so consumers can pin and migrate deliberately.
This sourceSpecifies MAJOR.MINOR.PATCH versioning where incompatible API changes require a major-version bump, letting consumers pin and migrate deliberately — the versioned-commitment piece of the bundle.
Supported in partVerified against the work's full text
SemVer supplies only the versioned-commitment element: major bumps signal breaking changes so dependents can bound version ranges and migrate deliberately.
“Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.”
- The published artifact is the library; addressability is the registry coordinate (a stable name-and-version handle) every dependent can reference; the open license is a permissive license file granting reuse and derivative rights without per-use permission; the re-use-ready form is a conventional package layout with a machine-readable manifest that build tooling consumes without bespoke translation; public access is the registry's open download with no paywall or membership gate; and the versioned commitment is semantic-versioning discipline, where breaking changes are signaled by a major-version bump so consumers can pin and migrate deliberately.
- Retired Term
- The write/read decoupling is precise — the function is "gone for write" (discouraged for new call sites) but "still there for read" (existing call sites resolve) — and the most common failure is dropping the migration signal: a silent removal in a minor version breaks every downstream caller the maintainer does not control, which is exactly why semantic-versioning discipline reserves removals for major versions and pairs deprecation with a documented successor and timeline.
This sourceSpecifies that backward-incompatible removals require a major version bump, while marking functionality deprecated requires a minor bump, pairing deprecation with a documented successor and timeline.
Supported in partVerified against the work's full text
SemVer ties removals to major releases and deprecation to a prior minor release; it does not state the write/read framing or that silent removal is the most common failure.
“Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.”
- The write/read decoupling is precise — the function is "gone for write" (discouraged for new call sites) but "still there for read" (existing call sites resolve) — and the most common failure is dropping the migration signal: a silent removal in a minor version breaks every downstream caller the maintainer does not control, which is exactly why semantic-versioning discipline reserves removals for major versions and pairs deprecation with a documented successor and timeline.
- Supersession
- In software it is major-version replacements with deprecation periods, endpoints marked deprecated with pointers to successors, and multi-year language-version transitions.
This sourceA backward-incompatible (breaking) API change increments the MAJOR version, so a major-version bump signals that the prior version is superseded for going-forward use — the software form of explicit, declared replacement.
Supported in partVerified against the work's full text
SemVer ties deprecation to a prior minor release before removal in a major release, supporting the major-version and deprecation-period part only.
“Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.”
- In software it is major-version replacements with deprecation periods, endpoints marked deprecated with pointers to successors, and multi-year language-version transitions.
Mechanisms¶
- API Governance Policy
- Following a published, uniform deprecation practice — and semantic versioning so a version number actually signals compatibility — is what separates legitimate interface stewardship from self-preferencing.
This sourceDefines semantic version numbers so changes to the number communicate specified compatibility implications.
- Following a published, uniform deprecation practice — and semantic versioning so a version number actually signals compatibility — is what separates legitimate interface stewardship from self-preferencing.
- Edition and Manifestation Catalog
- Its version-status discipline follows a convention like Semantic Versioning, where the number itself signals when a release replaces and breaks from the one before.
This sourceRequires semantic-version numbers to communicate incompatible, backward-compatible, and patch-level changes through major, minor, and patch increments.
- Its version-status discipline follows a convention like Semantic Versioning, where the number itself signals when a release replaces and breaks from the one before.
- Fragment Versioning Log
- It follows the logic of semantic versioning — a disciplined, meaningful version scheme so that a label communicates the significance of a change, not just its sequence.
This sourceDefines a version-number scheme whose major, minor, and patch increments communicate the compatibility significance of a change.
- It follows the logic of semantic versioning — a disciplined, meaningful version scheme so that a label communicates the significance of a change, not just its sequence.
- Interface Control Document or Service Contract
- The discipline that keeps it honest is version discipline backed by conformance tests as the real source of truth: the contract is trustworthy only as far as something checks that both sides still obey it.
This sourceSemantic Versioning (n.d.). Identifies version discipline as a feature of an interface contract.
- The discipline that keeps it honest is version discipline backed by conformance tests as the real source of truth: the contract is trustworthy only as far as something checks that both sides still obey it.
- Partition Change Notice
- This is the same discipline as semantic versioning, which separates breaking from non-breaking changes and signals them in advance; a change notice applies that contract to a taxonomy instead of an API.
This sourceUses version increments to distinguish incompatible changes from backward-compatible additions and fixes.
- This is the same discipline as semantic versioning, which separates breaking from non-breaking changes and signals them in advance; a change notice applies that contract to a taxonomy instead of an API.
- Platform Extension Manifest
- Pins are predictable but brittle across platform updates; ranges survive updates, but only if the platform honors its versioning promise.
This sourceSemantic Versioning. (n.d.). Explains that tight dependency specifications cause version lock, loose specifications risk incompatible upgrades, and semantic-version compatibility promises enable bounded version ranges.
- Pins are predictable but brittle across platform updates; ranges survive updates, but only if the platform honors its versioning promise.
- Release Notes with Effective Date
- Paired with a version scheme that signals breakage — the intent behind semantic versioning
This sourceSemantic Versioning uses a major-version increment to signal incompatible public-API changes.
- Paired with a version scheme that signals breakage — the intent behind semantic versioning
- Semantic Diff Review
- Under Semantic Versioning
This sourceRequires a major-version increment for backward-incompatible public API changes rather than a patch increment.
- Under Semantic Versioning
- Semantic Versioning
- The discipline that keeps it honest is to tie the `MAJOR` decision strictly to the specification's rule — increment for any backward-incompatible change, and only for that
This sourceRequires a major-version increment when backward-incompatible changes are introduced to the public API.
- The discipline that keeps it honest is to tie the `MAJOR` decision strictly to the specification's rule — increment for any backward-incompatible change, and only for that
- Semantic Versioning & Deprecation Gate
- The discipline is to derive the bump from an actual behavioural diff — ideally the output of the conformance tests — rather than from intent, and to let the evidence, not the calendar, pick the number.
This sourceSemantic Versioning (n.d.). Requires version increments to follow actual changes in public-API behavior, distinguishing fixes, compatible additions, deprecations, and incompatible changes.
- The discipline is to derive the bump from an actual behavioural diff — ideally the output of the conformance tests — rather than from intent, and to let the evidence, not the calendar, pick the number.
- Semantic Versioning Policy
- The classification, not the author's mood, decides how the change is released.
This sourceSpecifies major, minor, and patch increments according to compatibility and the kind of change made.
- The classification, not the author's mood, decides how the change is released.
- Version / Context Note
- A reader on v3 is warned off in one line instead of debugging a mystery — the note follows the discipline of a scheme like Semantic Versioning,
This sourceDefines major-version increments as signals of backward-incompatible public API changes.
- A reader on v3 is warned off in one line instead of debugging a mystery — the note follows the discipline of a scheme like Semantic Versioning,
- Versioned Interface and Migration Contract
- Rather than mutate v1 and break every integration overnight, it publishes a contract: semantic versioning, so a breaking change only ever appears on a major bump;
This sourceSemantic Versioning (n.d.). Requires a major version increment for backward-incompatible public-API changes.
- Rather than mutate v1 and break every integration overnight, it publishes a contract: semantic versioning, so a breaking change only ever appears on a major bump;
- Versioned Merge Protocol
- Its strength is that it makes definition change safe and auditable — semantic versioning
This sourceRequires released versions to remain immutable, with every modification issued as a new version.
- Its strength is that it makes definition change safe and auditable — semantic versioning
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Read against the text for 7 of 21 citations: 1 supported, 6 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 1 other way.
Registry ID ref:7434a8049da4 · see in the full table