Software versioning

Versioning schemes vary widely, but most follow a numeric sequence with major, minor, and patch components. The major number increments for incompatible changes, minor for backward-compatible additions, and patch for bug fixes. This is formalized in Semantic Versioning (SemVer), a widely adopted specification that also allows pre-release identifiers like -alpha.1 or -rc.2.¹ Other schemes include date-based versions (e.g., Ubuntu 24.04), sequential build numbers, and marketing-driven versions that may skip numbers for promotional reasons. Version numbers are often accompanied by release names, such as Ubuntu's animal adjectives or Android's dessert codenames, which serve as memorable aliases.

The practice of numbering software versions dates back to the early days of computing. Unix, for instance, used simple numbers like V6 and V7 in the 1970s. Later, the rise of personal computing popularized decimal versions, such as MS-DOS 3.3 or Windows 95, which used a year-based marketing name. The open-source movement brought more rigorous schemes: the Linux kernel uses a three-part number where the second digit indicates stability (even = stable, odd = development).² The Python programming language famously used a similar odd/even minor version convention for development releases. These examples illustrate how versioning adapts to project needs, from simple sequential numbers to complex predictive indicators.

Beyond the common schemes, versioning has many niche practices. Some projects use epoch numbers in package managers like Debian's dpkg, allowing version sequences to reset when a new upstream scheme is adopted. Others use build metadata (e.g., +build.20240101) to identify exact builds without affecting precedence. The CalVer scheme (Calendar Versioning) uses dates, as seen in Ubuntu and Twisted. A notable edge case is the Windows 10 version, which was marketed as 10 but internally reported as 6.4 for compatibility reasons. Versioning also extends to data formats and APIs, where version numbers are embedded in URLs or headers to manage breaking changes. The ISO/IEC 19770-2 standard defines software identification tags, which include version information for asset management.³

Effective versioning requires clear communication and discipline. A common pitfall is version inflation, where numbers are incremented without meaningful changes, eroding trust. Another challenge is managing pre-release versions and release candidates, which must be clearly distinguished from stable releases. Tools like semver and calver provide automated validation, and many projects adopt a versioning policy documented in their contribution guidelines. For libraries and APIs, semantic versioning is crucial for dependency resolution, as seen in package managers like npm and pip, which rely on version ranges to install compatible versions.⁴ Ultimately, the goal is to make version numbers meaningful to both humans and machines, balancing simplicity with expressiveness.

Semantic Versioning

A versioning scheme using MAJOR.MINOR.PATCH, where increments signal breaking changes, new features, and bug fixes respectively.

CalVer

Calendar Versioning, using dates like 2024.01 as version numbers.

Epoch

A leading number in package versions that overrides normal ordering, used to reset version sequences.

Build metadata

Additional identifiers appended to a version, such as a build timestamp, that do not affect precedence.