Seven Ways to Name a Release, Ranked by How Much Regret They Cause

Somewhere in America right now, a vice president of engineering is explaining to a board member why the product is running version "2024.11.3-hotfix-tuesday-FINAL." Naming conventions are one of the smallest decisions in software delivery and one of the longest-lived. Choose poorly, and the choice follows your organization for a decade.

What follows is an honest survey of the schemes in widest use — their genuine advantages, their genuine costs, and the kind of team each one actually fits.

1. Semantic Versioning: The Ledger of Intent

Major.minor.patch. Three numbers, each with a contract attached: breaking changes bump the major, additive features bump the minor, fixes bump the patch.

Pros: Semver is the closest thing the industry has to a shared language. Package managers understand it, dependency resolvers reason about it, and open-source contributors expect it. For any library or API consumed by other developers, it is less a convention than a civic duty.

Cons: The contract is only as good as the discipline behind it, and humans break semver constantly — a "minor" release quietly deprecates something, a "patch" ships a behavior change. Semver also says nothing about what changed, only how dangerous it is.

Fits: SDKs, libraries, public APIs. Anything a stranger depends on.

2. Calendar Versioning: The Honest Timestamp

Ubuntu popularized it with releases like 24.04; a growing number of product teams have followed. The version number is simply the date.

Pros: No debates about whether a change is "major." No number inflation after a decade of releases. Users can instantly tell how stale their installation is, which is a form of respect.

Cons: Calver deliberately abandons meaning. A release in February tells you nothing about whether it breaks anything. For products with strict compatibility promises, that opacity is a liability.

Fits: Products with a steady release train — browsers, operating systems, managed platforms — where freshness matters more than semantics.

3. Sequential Build Numbers: The Humble Counter

Build 4,817. No dots, no drama.

Pros: Impossible to get wrong, trivially sortable, and immune to philosophical arguments. Internal deployment pipelines love it.

Cons: Meaningless to humans. Build 4,817 versus 4,802 tells a customer nothing and tells your support team only slightly more.

Fits: Internal artifacts, continuous deployment pipelines where the version is a tracking number, not a communication tool.

4. Codenames: The Mythological Menagerie

Android named releases after desserts. Ubuntu names them after adjectives paired with animals. Countless teams name releases after Greek gods, Star Wars characters, or local craft beers.

Pros: Codenames are memorable and give releases a human identity. They are excellent for large, discrete milestones — "the Hermes release" sticks in a way "v14.2" never will.

Cons: Codenames carry zero ordering information. Nobody knows whether Hermes came before or after Persephone without consulting a wiki. They also invite an escalating creativity arms race that ages poorly in a board deck.

Fits: Major milestone releases layered on top of a numeric scheme — the codename for the era, the number for the record.

5. Semver Plus Channel Suffixes: The Enterprise Compromise

Version 8.2.1-lts, 2025.3-rc2, 4.0.0-beta.3. A base scheme with a maturity tag bolted on.

Pros: Communicates both meaning and audience in a single string. Long-term-support channels, release candidates, and beta rings all become legible at a glance — essential for teams running staged rollouts.

Cons: The suffixes multiply. Before long you are maintaining a taxonomy, and inconsistent suffix usage erodes the clarity the scheme was meant to provide.

Fits: Products with staged release processes — canary, beta, stable — and enterprise customers who plan around support lifecycles.

6. Hash-Based Versioning: The Auditor's Choice

Commit SHA as version. Maximum precision, zero narrative.

Pros: Perfect traceability. Every deployment maps to an exact point in history, which makes incident forensics dramatically easier.

Cons: Complete opacity to everyone outside the pipeline. Unpronounceable in an incident review.

Fits: Machine-to-machine contexts — container tags, internal artifact metadata — as a complement to, never a replacement for, a human-readable scheme.

7. The Ad Hoc Accident: The Default Outcome

No scheme, conventions accumulated by accident, version strings that reflect three reorganizations and a merger.

Pros: None, honestly.

Cons: Everything above.

Fits: Nobody. Yet a remarkable number of teams live here without realizing it.

A Decision Framework in Three Questions

When choosing, three questions resolve most of the debate.

First: who consumes the version number? If external developers do, semver is effectively mandatory. If only your own pipeline does, build numbers suffice.

Second: what does a release mean for compatibility? If releases carry breaking-change risk, the scheme must encode it. If releases are a steady train, dates are more honest.

Third: can a newcomer decode it in thirty seconds? Any scheme requiring a wiki page to interpret is a scheme your future self will curse.

The best-practiced answer for most product teams is a hybrid: semver or calver as the backbone, channel suffixes where staged rollouts exist, and codenames reserved for the occasional milestone worth remembering. Versioning is ultimately a communication decision dressed as a technical one. Choose the scheme that tells your audience the truth with the least explanation required — and write the convention down before the fourth reorganization makes the choice for you.