Semantic Versioning (SemVer)
SemVer stands for semantic versioning.
It is a versioning system that uses MAJOR.MINOR.PATCH numbers to communicate the scope and compatibility impact of a software change.
What it does
SemVer gives teams a consistent way to label releases.
It is commonly used to:
- Signal breaking changes
- Mark backward-compatible feature additions
- Distinguish small bug-fix releases
- Help teams reason about upgrade risk
- Standardize version communication across software releases
Core concepts
Major, minor, patch
Under SemVer:
MAJORchanges signal breaking compatibility changesMINORchanges signal backward-compatible feature additionsPATCHchanges signal backward-compatible bug fixes
Compatibility signal
SemVer is valuable because version numbers communicate expected change impact, not just sequence.
Release discipline
SemVer works best when teams apply it consistently and honestly.
If version numbers do not match the actual change impact, the versioning scheme loses value.
Common use cases
- Software package versioning
- Plugin and library releases
- Release planning
- Dependency upgrade decisions
- Changelog communication
Practical notes
- SemVer is a communication convention, not a guarantee of perfect upgrade safety.
- Some projects claim SemVer but still ship breaking changes in minor or patch versions.
- In plugin ecosystems such as WordPress, SemVer can be helpful, but not every plugin follows it strictly.
- SemVer is especially useful when teams need to evaluate upgrade risk quickly during a release or deployment.
Frequently Asked Questions
What does 1.4.2 mean in SemVer?
It means major version 1, minor version 4, and patch version 2.
Does a patch release mean no breaking changes?
Under strict SemVer, yes. In real projects, you still need judgment because not every team applies SemVer consistently.
Is SemVer required for software releases?
No. It is a widely used convention, not a universal rule.