Versioning

About semantic versioning

APM relies on semantic versioning in order to ensure compatibility when installing and updating packages.

This consists of 3 numeric values separated by dots, eg 3.1.15, named MAJOR.MINOR.PATCH. These version numbers are incremented based on the following:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

Incrementing semantic versions in published packages

To help developers who rely on your code, we recommend starting your package version at 1.0.0 and incrementing as follows:

Status	Stage	Rule	Example
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

Version Ranges

You can use version ranges to specify what sort of updates your package can accept in your package.json.

For example, for updates to a v1.0.0 version of a package you can use:

• 1.0.x: to accept patch releases;
• 1.x.x: to accept minor releases;
• x.x.x: to accept major releases (i.e. the latest)

Generally accepting minor or patch releases for a dependency is the best approach. Major releases will often be breaking.