What Is Semantic Versioning?
Semantic versioning is a versioning scheme where a version number like 2.4.1 encodes what kind of change it represents.
A version number can be arbitrary, or it can carry meaning. Semantic versioning (SemVer) makes the number meaningful: by reading it, you can tell whether an update is a safe bug fix, a backward-compatible feature, or a breaking change.
The major.minor.patch scheme
A SemVer version has three parts: MAJOR.MINOR.PATCH. You increment MAJOR for incompatible, breaking changes; MINOR for new features that are backward compatible; and PATCH for backward-compatible bug fixes. So 2.4.1 means major version 2, with four feature additions and one patch since the last minor.
What each bump signals
- PATCH (2.4.0 -> 2.4.1): a bug fix, safe to adopt.
- MINOR (2.4.1 -> 2.5.0): new features, still backward compatible.
- MAJOR (2.5.0 -> 3.0.0): a breaking change; review before upgrading.
An example
A library at 1.2.0 fixes a bug and releases 1.2.1, users can upgrade without thinking. It then adds a new optional feature and releases 1.3.0, still safe. Later it removes a deprecated function, a breaking change, so it releases 2.0.0, signaling that users must check their code before upgrading.
Why it matters for dependencies
When your project depends on many libraries, SemVer lets you express which updates to accept automatically. A rule like "accept patches and minors but not majors" relies entirely on libraries following SemVer honestly. This is what makes automated dependency updates safe rather than reckless.
Automating it
Many teams automate version bumps based on commit messages: a fix commit bumps the patch, a feature bumps the minor, a breaking-change marker bumps the major. This removes human guesswork and keeps versions truthful, which is what downstream consumers depend on.
Key takeaways
- SemVer encodes change type as MAJOR.MINOR.PATCH.
- Major means breaking, minor means new features, patch means fixes.
- It lets dependency tools accept safe updates automatically.