Compare semantic versions and test version ranges. Validate semver strings and calculate version increments.
Semantic Versioning (SemVer) is a versioning convention that communicates the nature of changes between software releases through a structured three-part version number: MAJOR.MINOR.PATCH. By following SemVer, package authors tell consumers exactly what to expect from an upgrade — whether it will break existing integrations, add new features, or fix bugs.
SemVer (semver.org) is the standard versioning scheme for npm, Cargo (Rust), Go modules, Composer (PHP), and most modern package ecosystems. Understanding SemVer is essential for managing dependencies, writing version constraints, and making informed upgrade decisions.
| Component | When to Increment | Example | Signal to Users |
|---|---|---|---|
| MAJOR (X.0.0) | Breaking changes to the public API | 2.0.0 → 3.0.0 | Code changes required to upgrade |
| MINOR (0.X.0) | New features, backward-compatible | 2.3.0 → 2.4.0 | New capabilities, existing code works |
| PATCH (0.0.X) | Bug fixes, backward-compatible | 2.4.1 → 2.4.2 | Safer to upgrade, existing code works |
| Format | Meaning | Example |
|---|---|---|
| 1.0.0-alpha | Pre-release: unstable, may change | Testing, early access |
| 1.0.0-beta.2 | Pre-release with iteration | Beta testing |
| 1.0.0-rc.1 | Release candidate | Final testing before stable |
| 1.0.0+build.123 | Build metadata (ignored in precedence) | CI/CD tracking |
| Syntax | Meaning | Accepts |
|---|---|---|
| ^1.2.3 | Compatible with 1.x.x | >=1.2.3, <2.0.0 |
| ~1.2.3 | Approximately 1.2.x | >=1.2.3, <1.3.0 |
| >=1.2.3 | Minimum version | 1.2.3 and above |
| 1.2.x | Any patch version | >=1.2.0, <1.3.0 |
| * | Any version | Everything |
Semantic Versioning is a versioning scheme that uses three numbers in the format MAJOR.MINOR.PATCH. Major version changes indicate breaking changes, minor version changes add new features that are backward compatible, and patch version changes indicate bug fixes. This system helps developers communicate the impact of updates clearly.
The caret (^) allows changes that do not modify the left-most non-zero digit, meaning it allows minor and patch updates but not major updates. For example, ^1.2.3 allows versions from 1.2.3 to less than 2.0.0. The tilde (~) allows only patch-level changes, so ~1.2.3 allows versions from 1.2.3 to less than 1.3.0.
Prerelease versions use suffixes like -alpha, -beta, or -rc followed by optional numbers (e.g., 1.0.0-beta.1). They indicate unstable versions still under development. Prerelease versions have lower precedence than the normal version, so 1.0.0-alpha comes before 1.0.0. Use them to distribute early versions for testing.
Version comparison follows a left-to-right precedence. First the major versions are compared, then minor, then patch. If these are equal, prerelease versions are compared alphabetically and numerically. Build metadata (after the + sign) is ignored in comparisons. For example, 2.0.0 is greater than 1.9.9 and 1.0.0 is greater than 1.0.0-beta.
Prerelease identifiers (after the hyphen) affect version precedence and indicate unstable releases. Build metadata (after the plus sign) provides additional information like build numbers or commit hashes but is completely ignored during version comparison. For example, 1.0.0+build.123 is equal to 1.0.0+build.456 in terms of precedence.
Enter a version range using npm-style syntax and a list of versions to test. The tool shows which versions satisfy the range and which do not. It also identifies the minimum and maximum satisfying versions. This is useful for understanding dependency resolution and checking package compatibility.
Increment MAJOR when you make incompatible API changes that require users to modify their code. Increment MINOR when you add functionality in a backward compatible manner. Increment PATCH when you make backward compatible bug fixes. Following these rules helps users understand the risk of updating to a new version.