W3cubDocs

/npm

Semantic versioning and npm

Semantic versioning is a standard that a lot of projects use to communicate what kinds of changes are in this release. It's important to communicate what kinds of changes are in a release because sometimes those changes will break the code that depends on the package.

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:

  • Bug fixes and other minor changes: Patch release, increment the last number, e.g. 1.0.1
  • New features which don't break existing features: Minor release, increment the middle number, e.g. 1.1.0
  • Changes which break backwards compatibility: Major release, increment the first number, e.g. 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:

  • Patch releases: 1.0 or 1.0.x or ~1.0.4
  • Minor releases: 1 or 1.x or ^1.0.4
  • Major releases: * or x

You can also specify more granular semver ranges.

© npm, Inc. and Contributors
Licensed under the npm License.
npm is a trademark of npm, Inc.
https://docs.npmjs.com/getting-started/semantic-versioning