Software versioning is the practice of assigning identifiers to successive states of a software product so people and tools can distinguish releases, track changes, and manage compatibility. Version labels appear in user interfaces, package repositories, file names and deployment manifests. They work together with source control and release processes to signal whether an update is a small bugfix, an added feature, or a change that may break backward compatibility. For general context about software, see software.

Core concepts and terminology

A version identifier can be numeric, textual or mixed. Typical elements include a major number, a minor number and a patch/revision number, but some projects use dates, code names or commit hashes. Common complementary concepts are:

  • Release — a packaged state of the code intended for distribution.
  • Patch — a small update that fixes bugs or security issues.
  • Pre-release — labels such as alpha, beta or rc (release candidate) that indicate instability or ongoing testing.
  • Build metadata — extra non-functional information like build timestamps or identifiers from continuous integration systems.

Common versioning schemes

Several schemes are widely used; projects choose one based on how they want to communicate compatibility and pace of change:

  • Semantic versioning (MAJOR.MINOR.PATCH) — conveys breaking changes, new features, and bug fixes at different positions in the number. This approach helps package managers and developers reason about API compatibility.
  • Date-based versioning — uses a date or year.month form to communicate release time; useful for regularly scheduled releases.
  • Sequential or incremental — simple increasing numbers that track the order of releases without implying compatibility guarantees.
  • Named releases — code names or associative labels (for example, distributions that use animal names); these are often paired with a numeric identifier.

Uses, examples and interactions with tooling

Version identifiers play multiple roles in software management: dependency resolution in package managers, API versioning for web services, coordinating upgrades in distributed systems, and labeling artifacts in continuous integration pipelines. A small bugfix should typically increment the patch portion of a version, while an incompatible API change prompts a major increment. Projects often publish patches and changelogs so users can understand what changed and whether to upgrade.

Best practices and notable considerations

Good versioning practice includes tagging releases in version control, maintaining a clear changelog, automating version bumps in CI/CD, and documenting what each segment of the identifier means for your project. Avoid misleading schemes (such as silently changing compatibility guarantees) and prefer predictable, machine-readable formats when dependencies are automated. For guidance on release processes and management, teams often consult resources about release practices.

Versioning is both a technical mechanism and a communication tool: when applied consistently it reduces upgrade friction, improves developer collaboration, and helps users make informed choices about updating software.