Semantic versioning in plain language

Semantic versioning gives version numbers a meaning. A version such as 2.4.1 has three parts: major, minor and patch. The idea is that you can tell from the number alone how risky an update is.

A patch release fixes bugs without changing how the software is used, so 2.4.1 to 2.4.2 should be safe to install. A minor release adds features in a backward-compatible way, so 2.4 to 2.5 should not break existing code. A major release, from 2.x to 3.0, is allowed to break compatibility, and the release notes should list exactly what changed.

There are caveats. Versions below 1.0 are considered unstable, and any change may break things. The rules are a promise by the maintainers, not a guarantee, and not every project follows them strictly, so reading the changelog before a major update is always worth the time.

For your own projects, two habits help. Declare dependency ranges carefully: a caret range such as ^2.4.1 in npm accepts new minor and patch releases, while a tilde range such as ~2.4.1 accepts only patches. And commit the lock file, which records the exact versions used, so that every machine and every build gets the same result.

If you publish a library, treat the public interface as the contract. Removing a function, changing what it returns or tightening what it accepts belongs in a major release, even when the change feels small to you.