Versioning Strategy: SemVer vs CalVer

Two versioning approaches.

SemVer

How software is versioned is a small decision that ripples across many years of releases. Pick the wrong scheme and customers cannot tell which versions are safe to upgrade to; pick the right scheme and the version itself communicates the upgrade impact. The two dominant schemes are Semantic Versioning (SemVer) and Calendar Versioning (CalVer); each fits different kinds of software.

What SemVer offers:

• MAJOR.MINOR.PATCH structure.: Three numbers separated by dots. MAJOR increments on breaking changes; MINOR on backwards-compatible additions; PATCH on backwards-compatible bug fixes. The number itself encodes the upgrade impact.
• Breaking changes signal MAJOR bump.: When a new release breaks the contract (removes API, changes behavior, requires user code changes), the major version increments. Customers see the major bump and know to budget for migration work.
• Backwards-compatible additions are MINOR.: New features that do not break existing usage land in MINOR releases. Customers can upgrade safely; the new features are available but not required. The minor bump signals "you might want to update."
• Bug fixes are PATCH.: Bug fixes that do not break the contract land in PATCH releases. Customers should always upgrade to the latest patch within their major version. The patch bump signals "you should update for the fix."
• Best for libraries.: Library consumers are other developers. Their build systems pin against semver ranges (^1.2.0 means "anything compatible with 1.2.0"). The pinning works because the version conveys upgrade impact. SemVer is the dominant scheme for npm packages, Cargo crates, Maven artifacts, Python wheels.

SemVer is the right answer for any software where the consumer is a developer who pins against version ranges. The discipline of correctly applying SemVer (major bump for breaking changes, even subtle ones) is what makes the scheme valuable.

CalVer

Calendar Versioning encodes the date of the release into the version number. The semantic content is "this is the release from year X month Y" rather than "this release has these compatibility properties." For software with regular release cadence and where upgrade compatibility is managed differently, CalVer is the right fit.

• YYYY.MM.PATCH structure.: The year and month are explicit; the patch number distinguishes multiple releases within the month. Examples: Ubuntu 24.04, JetBrains 2026.1, pip 24.0. The format varies but the principle is the same.
• Date-based, not impact-based.: The version tells you when the release shipped, not what changed. This is information CalVer software has decided is more useful than impact metadata. Customers ask "are we on the latest" and "how old is our version"; both are easily answered.
• Best for applications.: Applications and end-user software where customers do not pin against version ranges. The customer just wants to be on a recent version; the date encoding tells them how recent they are. SemVer's compatibility metadata is less useful here because the customer is not building against an API.
• Predictable cadence.: CalVer typically pairs with regular release schedules (annually, semi-annually, quarterly, monthly). The version number reflects the schedule. Customers can plan around it: "we upgrade to the new version each year in March."
• Long-term support windows.: Many CalVer projects designate specific releases as LTS (long-term support). Ubuntu 24.04 LTS is supported for five years. The version encodes both when it shipped and the support window. The model maps well to enterprise customers who upgrade infrequently.

CalVer is the right answer for software with predictable release cadence where customers care about recency rather than compatibility. Most consumer applications, OS distributions, and IDEs use CalVer for this reason.

Pick

The choice between SemVer and CalVer is mostly determined by the consumer's relationship with the version. Different software has different relationships; pick the scheme that matches the relationship.

• Library: SemVer.: If your software is consumed as a dependency by other code (libraries, SDKs, frameworks), use SemVer. The compatibility metadata is what consumers' build systems need; without it, dependency management becomes guesswork.
• App with regular releases: CalVer.: If your software is consumed as a product (applications, services, OS distributions), CalVer matches better. The customer cares about recency; the version conveys it directly.
• Both have a place.: Neither scheme is universally correct. Many companies use SemVer for their SDKs and CalVer for their applications. The choice is per-product, not company-wide.
• Hybrid schemes exist.: Some software uses combinations: SemVer numbers within a CalVer-driven release schedule, or marketing-friendly version numbers (Microsoft Office 2024) backed by precise build numbers internally. The hybrid is sometimes the right answer when one scheme alone does not cover the use case.
• Whichever scheme, document it.: The versioning policy is documented so customers know what version numbers mean. "Major versions ship annually with breaking changes; minor versions ship monthly with additions; patches ship on demand for fixes." The policy becomes the contract.

Versioning is a small discipline that pays back over years of releases. Nova AI Ops integrates with release pipelines, surfaces the version-bump decisions per release, and tracks how customers are distributed across the version space so the team can see whether the versioning communication is actually working.