How to use Semantic Versioning

It's important to communicate the extent of changes in a new release of code, because sometimes updates can break code that a package needs (called dependencies). Semantic versioning (semver) is a standard that was designed to solve this problem.

Semver for Publishers

If a project is going to be shared with others, it should start at 1.0.0, (though some projects on npm don't follow this rule).

After this, changes should be handled as follows:

Code status Stage Rule Example version
First release New product Start with 1.0.0 1.0.0
Backward compatible bug fix Patch release Increment the third digit 1.0.1
Backward compatible new feature Minor release Increment the middle digit and reset last digit to zero 1.1.0
Changes that break backward compatibility Major release Increment the first digit and reset middle and last digits to zero 2.0.0

Semver for Consumers

As a consumer, you can specify which kinds of updates your app can accept in the package.json file.

If you were starting with a package 1.0.4, this is how you would specify the ranges:

Learn More

For a great tool you can use to learn about how semver works with your favorite packages, see the npm semver calculator.

For more about using semantic versioning with package.json files, see Chapter 5.

For another way to label releases, learn about npm dist tags, and how they relate to semantic versioning.

          Found a typo? Let us know!

npm Services

Getting started

Private packages


Using npm

CLI commands

Configuring npm

View All On One Page