Semantic versioning (SemVer) is a standard for defining the version numbers. A version number consists of three numbers separated by periods (
Major (Breaking) X
- while being developed (i.e. before being officially released), this number is zero (
- when officially released, the number should increment to one (
- if a release breaks backwards compatibility, the number should increment by one and the following numbers reset to zero (e.g.
Minor (Feature) Y
- when a new feature is added in a backwards compatible way, the number should increment by one and the following number reset to zero (e.g.
Patch (Bugfix) Z
- when a bug is fixed, the number should increment by one (e.g.
Example History of a Project
1.0.0Initial release (e.g. being used on a production site)
1.0.1Fix bug where isPrime() returns true for negative numbers (e.g. -7)
1.1.0Add new isPalindrome() function
1.1.1Fix bug in isPalindrome() function to handle spaces (e.g. “taco cat”)
1.2.0Add new isOdd() function
2.0.0Remove isLucky() function (this function was included in the original release but is no longer supported)
2.0.1Fix documentation around isLucky() removal
SemVer and the “Size” of Changes
A common pitfall when defining version numbers is wanting to define the version number based on the “size” of a change.
The number of lines changed has no impact on version number.
Major can be “Small”
A major version increase (e.g. from
2.0.0) can be as “small” as removing a single line of code.
A Bugfix can be “Large”
A bugfix version increase (e.g. from
1.3.6) could involve adding hundreds of lines of code.