Semantic Versioning is a versioning scheme for software that uses a three-part number format: MAJOR.MINOR.PATCH. It provides a standardized way to communicate the nature of changes in a release. Increment the MAJOR version for incompatible API changes, MINOR for backward-compatible new functionality, and PATCH for backward-compatible bug fixes. Optional pre-release labels (like -alpha or -rc.1) and build metadata (like +build.2024) can be appended for additional context. The full specification is maintained at semver.org.

The "v" prefix (e.g., v1.0.0) is not part of the strict Semver 2.0.0 specification. While many package managers and tools (like npm, Git tags) accept or use the "v" prefix for display purposes, the core Semver standard defines a version as starting directly with a numeric MAJOR component. If you encounter v1.0.0, the valid Semver equivalent is 1.0.0. Our validator follows the strict spec to help you ensure maximum compatibility.

Pre-release identifiers follow the main version after a hyphen (-). Key rules include:

• Identifiers are separated by dots (.), e.g., 1.0.0-alpha.1.
• Each identifier may contain only alphanumeric characters and hyphens ([0-9a-zA-Z-]).
• Numeric identifiers must not have leading zeros. 01 is invalid; 0 is valid.
• An identifier cannot be empty.
• Examples of valid pre-releases: -alpha, -rc.1, -0.3.7, -x.y.z.1.
• Examples of invalid pre-releases: -01 (leading zero), -alpha..1 (empty identifier).

Build metadata is appended after a plus sign (+) and is ignored when determining version precedence. Unlike pre-release identifiers, build metadata identifiers can have leading zeros (e.g., +01 is valid). They also use dots as separators and may contain alphanumeric characters and hyphens. A version like 1.0.0-alpha+001 is perfectly valid: -alpha is the pre-release (affects precedence), and +001 is build metadata (informational only, does not affect precedence).

Version comparison follows a specific hierarchy:

1. Compare MAJOR numerically. Higher MAJOR = newer version.
2. If MAJOR is equal, compare MINOR numerically.
3. If MINOR is equal, compare PATCH numerically.
4. If all three are equal, a version without a pre-release tag is newer than one with a pre-release tag (e.g., 1.0.0 > 1.0.0-alpha).
5. If both have pre-release tags, compare each dot-separated identifier: numeric identifiers are compared numerically, alphanumeric identifiers are compared lexically in ASCII order. Numeric identifiers always have lower precedence than non-numeric ones.
6. Build metadata is ignored in precedence calculations.

Yes! A version can include both a pre-release label and build metadata simultaneously. The format is: MAJOR.MINOR.PATCH-PRERELEASE+BUILD. For example, 2.1.0-rc.3+build.20240315 is a valid Semver version. The pre-release (-rc.3) affects version precedence, while the build metadata (+build.20240315) is purely informational.

Common mistakes when writing semantic versions include:

• Using a "v" prefix (v1.0.0) — not part of strict Semver.
• Leading zeros in version numbers or pre-release numeric identifiers (01.02.03, 1.0.0-01).
• Missing PATCH version (1.0 instead of 1.0.0).
• Empty identifiers in pre-release or build metadata (1.0.0-alpha..1).
• Using invalid characters like underscores or spaces in pre-release/build metadata.
• Putting build metadata before pre-release (1.0.0+build-alpha is invalid; use 1.0.0-alpha+build).

Absolutely. While Semver is widely associated with the npm/Node.js ecosystem, it is used across many programming languages and package managers, including Rust (Cargo), Go (modules), Python (PEP 440 compatible), Ruby (Gems), PHP (Composer), .NET (NuGet), Dart (Pub), and many more. It has become the de facto standard for communicating software version compatibility across the entire open-source ecosystem.