TrunkVer

Original Article ↗ Hacker News Discussion ↗

SemVer “compatibility” debate

  • Many argue TrunkVer is only syntactically SemVer-compatible (three numbers + prerelease/build), but not semantically compatible.
  • Objection: treating every build as a major version discards SemVer’s core meaning (“major = breaking change”), turning versions into opaque identifiers.
  • Supporters respond that for trunk-based/continuous delivery, the safe assumption is “any change might be breaking,” so major-only increments are defensively correct.
  • Some note the TrunkVer spec itself acknowledges it does not respect SemVer’s semantic interpretation, only the format.

Intended vs problematic use cases

  • Supporters position TrunkVer for:
    • Continuously delivered, trunk-based internal services and web apps.
    • Systems where users have no choice of version and compatibility is managed socially/organizationally (coordination, rollouts), not via version numbers.
    • Tooling that expects SemVer-like strings but only needs a sortable, unique identifier.
  • Critics stress it is not suitable for:
    • Libraries or APIs consumed via package managers, where compatibility ranges matter.
    • Products with multiple independent consumers, differing deployment cadences, or data/API compatibility concerns.
  • Concern: once promoted, some teams will apply TrunkVer to libraries, making dependency resolution and compatibility reasoning much harder.

Timestamp and build-metadata concerns

  • Using build timestamps as the “major” field:
    • Can misorder versions when old code is rebuilt later.
    • Entangles volatile data (build time, CI job ID) with artifacts, harming reproducible builds.
    • Produces long, hard-to-scan identifiers; some say a simple incrementing integer or git SHA plus external metadata lookup is cleaner.
  • Git hashes are not inherently ordered; timestamps and commit dates can be manipulated, so monotonicity is not guaranteed.
  • The published EBNF for TrunkVer is criticized as inconsistent with its own textual description.

Relationship to SemVer and other schemes

  • Several commenters frame it as:
    • SemVer: communication/threat indicator about API compatibility.
    • TrunkVer: audit/engineering identifier for “what exactly is running where.”
  • Alternatives discussed: plain sequential numbers, CalVer (calendar versions), git SHA-only, git-height-based schemes (e.g., Nerdbank Git Versioning), PEP 440, SemVer plus separate build IDs.
  • Broader thread notes SemVer is valuable but imperfect; it encodes developer intent, not guaranteed reality, and is often over- or mis-applied outside library-like contexts.