Semantic Versioning (SemVer)

Semantic Versioning (SemVer, formalisé par Tom Preston-Werner co-fondateur GitHub en 2010) est une convention de versioning au format MAJOR.MINOR.PATCH (ex: 2.5.13) où chaque composant a une signification précise. Standard de facto pour libraries et APIs publiques, particulièrement dominant dans npm, Cargo, RubyGems, Maven, NuGet ecosystems.

Règles :
(1) MAJOR — incrémenté lors de breaking changes incompatibles API (ex: 2.x → 3.0.0 : suppression d'une fonction publique, changement signature, comportement différent).
(2) MINOR — incrémenté lors d'ajouts backward-compatible (nouvelles features sans casser existing API, ex: 2.4.x → 2.5.0 : nouvelle méthode ajoutée).
(3) PATCH — incrémenté pour bug fixes backward-compatible (ex: 2.5.12 → 2.5.13 : correction bug sans changement comportement attendu).
(4) Pre-release suffix optional : 2.0.0-alpha.1, 2.0.0-beta.3, 2.0.0-rc.2 (release candidate).
(5) Build metadata : 2.0.0+20240928 (ignoré pour comparison ordering).
(6) Special case : MAJOR=0 (0.x.y) signifie initial development unstable, breaking changes possibles in MINOR. Production-ready triggers 1.0.0.

Version ranges dans package managers : (1) npm/yarn : ^2.5.13 = compatible 2.x.x latest (>=2.5.13 <3.0.0), ~2.5.13 = patch updates (>=2.5.13 <2.6.0), exact 2.5.13. (2) Cargo : ^2.5.13 default ; (3) Maven : version ranges complex (rarely used).

Problèmes pratiques avec SemVer : (1) authors disagree what constitutes "breaking" — adding stricter validation = breaking? deprecating method = breaking? Renaming internal type exposed in TypeScript = breaking? ; (2) trust issue : 30% of MINOR/PATCH releases break consumers somehow per studies (Bogart et al.) ; (3) transitive deps cascading versions hell (left-pad incident npm 2016, log4j Dec 2021 — fixing transitively buried libs hard); (4) ecosystem fatigue (constant updates exhausting maintenance).

Alternatives/Compléments : (1) Calendar Versioning (CalVer) — YYYY.MM.DD format, used by Ubuntu (24.04), Python (no, Python uses PEP 440), JetBrains (2024.1), Twisted (24.7.0). Pros : clear release recency, no semantic debate ; Cons : doesn't signal breaking changes. (2) ZeroVer — humorous 0.x.y forever convention (parodying many projects staying on 0.x). (3) Conventional Commits + automated semver via tools (semantic-release, release-please) — commit messages (feat:, fix:, BREAKING CHANGE:) drive automated version bumps.

Libraries publishing best practices : (1) maintain CHANGELOG.md (Keep a Changelog format) ; (2) deprecation warnings 1-2 minor versions before removal ; (3) test against multiple versions of dependencies ; (4) clearly document public API surface (vs internal types not subject to semver) ; (5) consider Long-Term Support (LTS) versions for users wanting stability.

Tools : (1) semantic-release — fully automate version bumps + changelog + npm publish from commit messages ; (2) release-please (Google) — similar, generates release PRs ; (3) standard-version — bump version + changelog locally ; (4) Changesets (npm/monorepo focus) ; (5) commitlint + husky — enforce Conventional Commits in CI. Compétences DOP-C02, GH-FOUND.