TrunkVer

Original Article ↗ Hacker News Discussion ↗

A proposed versioning scheme called TrunkVer, which encodes build timestamps and git metadata into a SemVer-shaped string, is prompting debate over what version numbers are actually for. Supporters argue it’s ideal for continuously deployed, trunk-based applications where each build just needs a unique, sortable identifier and no compatibility guarantees are made. Critics counter that calling it “SemVer-compatible” is misleading, that it breaks assumptions needed by package managers and downstream consumers, and that it’s unsuitable for libraries or systems where version numbers are expected to convey semantic compatibility.

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.