Semantic Versioning, or SemVer, is a versioning scheme for software that conveys meaning about the underlying changes. A SemVer version string looks like:

MAJOR.MINOR.PATCH

• MAJOR version (X.y.z):

  Incremented when you make incompatible API changes. Consumers may need to modify their code to upgrade.

• MINOR version (x.Y.z):

  Incremented when you add functionality in a backwards-compatible manner. Existing code continues to work; new features are available.

• PATCH version (x.y.Z):

  Incremented when you make backwards-compatible bug fixes. No new features—just stability and correctness improvements.

Pre-Release and Build Metadata

SemVer also supports optional extensions:

• Pre-release: 1.2.3-alpha.1

  Indicates that this is an unstable, pre-release version. Versions with pre-release tags have lower precedence than the same version without the tag.

• Build metadata: 1.2.3+20130313144700

  Provides build or environment information. Metadata does not affect version precedence.

Why Use SemVer?

• Predictability: Developers immediately know the impact of upgrading—whether it’s safe, adds features, or may break things.
• Dependency Management: Package managers (npm, pip, Maven, etc.) can automatically choose compatible versions.
• Communicates Intent: Clear signaling of bug fixes vs. new features vs. breaking changes.

Example

1.0.0 → 1.0.1: Patch fix (e.g., typo correction).

1.0.1 → 1.1.0: New backwards-compatible feature (e.g., new API endpoint).

1.1.0 → 2.0.0: Breaking change (e.g., removal of deprecated function).

By following SemVer’s rules, projects maintainers and consumers benefit from a clear, consistent versioning policy.