Semantic Versioning 2.0.0

Preston-Werner, T. (2013). Semantic Versioning 2.0.0.

Type

Standard

Intellectual base

Reference work

Year

2013

Link

https://semver.org/

Cited from

biology_ecology, computer_science, economics_finance, education_pedagogy, engineering_design, synthesized, systems_cybernetics

Cited by

8 citations across 8 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.

• 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).
• 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.
• 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.

• 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.

• 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.

• 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.

Mechanisms

• 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.

Verification

This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 1 other way.

• https://semver.org/spec/v2.0.0.html ×2

Registry ID ref:7434a8049da4 · see in the full table