To keep the JavaScript ecosystem healthy, reliable, and secure, every time you make significant updates to an npm package you own, we recommend publishing a new version of the package with an updated version number in the package.json file that uses the semantic versioning guidelines.
| Code Status | Stage | Rule | Example Version |
|---|---|---|---|
| First Release | New product | Start with 1.0.0 | 1.0.0 |
| Backward compatible bug fixes | Patch release | Increment the third digit | 1.0.1 |
| Backward compatible new features | 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 |
You might find lots of package that starts with 0, like 0.0.1. It means they don't have any stable version yet. The package is available just for testing and it is in development stage and it is yet to be stable. When it become stable, it will start with 1 like 1.0.0.
When there is a new release but there is no new feature, just minor bug fixes and doesn't break the existing code where that package is being used, this release is called Patch Release. For this case the last digit of the version number is incremented.
When there is a new release, but there is a new feature and functionality like some methods to the API. This feature might also contain other minor bug fixes. This feature doesn't break the existing code where it is being used. This release is called Minor Release. In this case the middle digit of the version number is incremented.
When there is a new feature or functionality, or bug fixes that might break the code where it is being used is called Major Release. For this case the first digit of the version number is incremented.
Let's say you have a package with some dependencies. Now if your dependencies updates, it might impact your package or module. For example, one of your dependencies has a major release that might break your code. To solve this you can specify what version your package can accept. You can specify which update types your package can accept from dependencies in your package’s package.json file.
To limit patch releases you can use one of the following formats -
1.0 1.0.x ~1.0.4
In the first format of the version, there is no third digit. It means your package can accept any patch releases.
In the second format we have used x in place of third digit. It alos means your package can accept any patch releases.
In the third format we have used a tide symbol ~ in front of the version, it means it can accepts any patch releases which greater than or equals to the version 1.0.4. If the version is less than 1.0.4, your package won't accept the updates.
To limit minor releases, you can use one of the following formats-
1 1.x ^1.0.4
Note that all of the above format can accept any patch releases.
In the first format, we have only the first digit of the version. It means your package will accept any patch releases and minor releases. But won't accept any major releases.
In the second format we have used x as the second number of the version. It means the same as the first format.
In the last format we have used ^ symbol to limit the version. It will accept any minor releases or patch releases where the version is greater than or equals to 1.0.4. However it won't accept any major releases.
To limit major releases, you can use one of the following formats -
* x
The both format means same. Your package can accepts any patch releases, minor releases and major releases.
"dependencies": {
"my_dep": "^1.0.0",
"another_dep": "~2.2.0"
},