How to use the semantic version comparator
- Type the first version, such as 1.9.3. A leading v is allowed.
- Type the second version, such as 1.10.0-rc.1.
- Optionally open the advanced options and paste a list of versions, one per line, to have them sorted from oldest to newest.
- Read which version is newer, the first part that differs, and the table that sets the parts side by side.
Formula
version = MAJOR.MINOR.PATCH, optionally -prerelease and +build
compare major, then minor, then patch as whole numbers
a version with a pre-release part is older than the same version without one
pre-release parts are compared one dot-separated piece at a time
build metadata is ignored
In a pre-release comparison, pieces made of digits are compared as numbers and come before pieces with letters, which are compared as text. A longer list of pieces wins when all earlier pieces match.
1.9.3 against 1.10.0-rc.1
The major numbers are both 1. The minor numbers are 9 and 10, and 10 is larger as a number, so 1.10.0-rc.1 is newer even though it is a release candidate and the other is a final release. The first part that differs is the minor number.
Sorting 1.0.0, 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-alpha.beta, 1.0.0-beta, 1.0.0-beta.2, 1.0.0-beta.11, 1.0.0-rc.1, 2.0.0, 1.10.0 and 1.9.9 gives 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-alpha.beta, 1.0.0-beta, 1.0.0-beta.2, 1.0.0-beta.11, 1.0.0-rc.1, 1.0.0, 1.9.9, 1.10.0 and 2.0.0.
Why not compare versions as text
As text, 1.10.0 sorts before 1.9.3 because the character 1 comes before 9. Semantic versioning compares each number as a number, so 10 is larger than 9. The same applies inside pre-release parts: beta.11 is newer than beta.2, even though the text 11 sorts before 2.
Numbers cannot have leading zeros in a valid version, and all three of major, minor and patch are required, so 1.2 and 01.2.3 are rejected with a message.
What the parts mean
In semantic versioning a major increase signals changes that can break existing users, a minor increase adds features without breaking, and a patch increase fixes bugs. The rules for ordering are fixed by the specification, but what a project promises with each number is for that project to say. Related developer tools include the hash generator and the CRC32 checksum calculator.
Assumptions and limits
- Versions follow the Semantic Versioning 2.0.0 format with all three numbers present. A leading v is removed.
- Version numbers can be as large as you like, because they are compared as exact whole numbers.
- Build metadata after a plus sign is shown but never changes the order.
- Other styles, such as calendar versions or four-part versions, are not covered.
Frequently asked questions
Is 1.10.0 newer than 1.9.3?
Yes. The minor numbers are compared as numbers, and 10 is greater than 9. Comparing them as text would give the wrong answer, which is a common mistake.
Is a release candidate newer than the previous release?
Yes, if its numbers are higher. 1.10.0-rc.1 is newer than 1.9.3. It is older than 1.10.0 itself, because a pre-release comes before the final version with the same numbers.
Do build numbers after a plus sign matter?
No. 1.0.0+build.1 and 1.0.0+build.2 have equal precedence. Build metadata is kept for information only.
Why was my version rejected?
It may have fewer than three numbers, a number with a leading zero, an empty pre-release piece, or characters other than letters, digits and hyphens. The message says which problem was found.