Introduction to the

To solve the dependency hell of software management, a system has been developed known as semantic version control, in which version numbers and how they are updated contain information about underlying code and changes made between adjacent versions.


It was founded by Gravatars founder and GitHub co-founder Tom Preston-Werner.

It can be divided into two major categories: official edition and advanced edition

Official version format

Major version. Minor version. The increment rule for the X.Y.Z version number is as follows:

  1. Major version number: when you make incompatible API changes
  2. Secondary version number: when you make a backward-compatible functional addition
  3. Revision number: When you make a backward compatible problem fix

X, Y, and Z are non-negative integers; For example, 1.0.0 -> 1.0.1 -> 1.1.0 does not allow padding with zeros, such as 01.0.0

Prior version format

Prior releases are released for testing before major releases or core features are released. There are three main formats

  1. Alpha: Internal beta
  2. Beta: public beta
  3. Rc: Release candiate

The prior version number can be added to the major version number. Second version number. Revision number “is followed as an extension. A hyphen followed by a string of hyphen. Delimited identifiers to decorate. For example, 1.0.0-alpha.1, 1.0.0-beta.2, 1.2.0-RC. 0, the last bit is the number information

Upgrade guide

  • The first official release started with 1.0.0
  • 1.0.0 release timing: By the time your software is used in a formal environment, it should have reached version 1.0.0. If you already have a stable API that users depend on, it will be version 1.0.0. If you’re worried about backward compatibility, this is version 1.0.0.
  • When the major version number is upgraded, the minor version number and revision number return to zero. When the second version is upgraded, the revision number returns to zero


npm semver

Semver is an implementation of the Semantic Versioning specification by the NPM team that resolves, calculates, and compares versions and version ranges.

  • Fixed versions: specific versions such as 0.2.0, 2.2.3, 2.1.4-RC.1.
  • Range version: a representation of versions that meet the rule, such as 1.2.3-2.3.4, 1.x, ^0.2.1, ~1.2.1, >1.4

Version number matching rules in NPM

In the rules of NPM dependence, mainly ^, ~, >, <, > =, < =, -, | |, x, * this a few kinds

When NPM install XXX is executed, it is preceded by ^ by default by the version number on which the installation depends

  • ^ : Indicates that the version number of the same major version is not less than the specified version, that is, the fixed major version number. For example, the current released versions are 2.0.0 and 1.9.0. ^1.1.3 corresponds to the installed version 1.9.0
  • ~ : indicates that the version number of the same major or minor version is not less than the specified version number, that is, the fixed major or minor version number. For example, ^1.1.3 matches 1.1.3, 1.1.4, and 1.1.5, but 2.0.0 and 1.2.0 do not
  • >, <, >=, <=, – : Specifies a range. For example, >1.0.0 will match 1.0.0, 1.1.2, 2.2.3, but not 0.1.2, 0.9.2. Note that 1.1.0-2.2.0 is marked with Spaces on both sides.
  • | | : said or 0.0.1 | | 0.3.0-15.5.0 will match to 0.01, 0.3.0, 0.3.1… 14.5.2, 15.5.0, not 0.2.2, 0.1.2
  • * and x: wildcard * corresponds to all version numbers, and 2.x corresponds to all version numbers whose major version is 2

Matching rules for previous version numbers

If the version number specified is not a prior version number, all prior versions will not be matched. If the specified version number is an earlier version number, the earlier version number that meets the condition is matched

For example ^ 15.3.0-RC.2 can be matched

  • 15.3.0 - rc. 2
  • 15.3.0 - rc. 3
  • 15.3.0
  • 15.3.1
  • 15.5.3

It won’t match

  • 15.3.0 - rc. 1
  • 16.1.0 - rc. 3
  • 15.3.0 - beta. 4



Reference documentation

  • Semantic versioning 2.0.0
  • NPM semver specification
  • NPM Semver Calculator Version number calculator