Walidator SemVer: Sprawdz format wersjonowania semantycznego

Czym jest wersjonowanie semantyczne?

Semantic Versioning (SemVer) is a versioning scheme that assigns meaning to each part of a version number. Created by Tom Preston-Werner, SemVer provides a universal convention for communicating the nature and impact of software changes through version numbers alone.

By following SemVer, developers and users can instantly understand whether an update introduces breaking changes, new features, or bug fixes — just by reading the version number. This predictability is crucial for dependency management in modern software ecosystems.

Format SemVer

A semantic version consists of three numeric components separated by dots: MAJOR.MINOR.PATCH.

• MAJOR — incremented when you make incompatible API changes. Going from 1.x.x to 2.0.0 signals that existing code may break
• MINOR — incremented when you add functionality in a backward-compatible manner. Going from 1.2.x to 1.3.0 means new features without breaking existing ones
• PATCH — incremented when you make backward-compatible bug fixes. Going from 1.2.3 to 1.2.4 means only bugs were fixed
• Each component must be a non-negative integer and must not contain leading zeros (1.02.3 is invalid)

Zakresy wersji

Package managers use version ranges to specify compatible dependency versions. Understanding these ranges is essential for reliable builds.

• Caret ranges (^1.2.3) — allow changes that do not modify the leftmost non-zero digit. ^1.2.3 means any version from 1.2.3 up to but not including 2.0.0
• Tilde ranges (~1.2.3) — allow patch-level changes only. ~1.2.3 means any version from 1.2.3 up to but not including 1.3.0
• Exact version (1.2.3) — only that specific version is acceptable, no flexibility

Zastosowania

Semantic versioning is the foundation of modern package management and release workflows.

• npm, pip, and Cargo — package managers rely on SemVer to resolve dependency trees and prevent breaking changes from reaching production
• CI/CD pipelines — automated systems use SemVer tags to trigger builds, publish releases, and generate changelogs
• API versioning — REST APIs use major versions in URLs (v1, v2) to maintain backward compatibility while evolving
• Library authors — publishing a library with proper SemVer signals to consumers when upgrades are safe

Pre-release i metadane

SemVer supports two optional extensions that add context to version numbers without affecting precedence rules.

• Pre-release identifiers — appended after a hyphen: 1.0.0-alpha, 1.0.0-beta.2, 1.0.0-rc.1. These indicate versions that are not yet stable and have lower precedence than the associated release
• Build metadata — appended after a plus sign: 1.0.0+build.123, 1.0.0-beta+exp.sha.5114f85. Build metadata is ignored when determining version precedence
• Pre-release versions are sorted using dot-separated identifiers: numeric identifiers sort numerically, alphanumeric identifiers sort lexically

FAQ

Is 0.x.x treated differently from 1.x.x?

Yes. In SemVer, version 0.x.x indicates initial development where anything may change at any time. The public API should not be considered stable. Once you release 1.0.0, you commit to following SemVer rules for all subsequent releases.

Can I use v as a prefix (v1.2.3)?

The SemVer specification does not include a v prefix — the canonical format is 1.2.3. However, many tools (Git tags, GitHub releases) conventionally use v1.2.3. Most validators accept both forms.

What happens if I forget to bump the major version for a breaking change?

Consumers who use caret ranges will automatically receive the update, and their builds may break unexpectedly. This is why SemVer discipline is critical — it is a social contract between library authors and consumers.