Upgrade to Semantic Versioning
Handle Major and Minor upgrades smoothly
--
Semantic versioning is a formal convention for specifying compatibility using a three-part format.
The format
This format can represent any version of software, say version 2.5.4
Here we have three periods . that split up the three parts of the version number.
Major . Minor . Patch
so 2.5.4 is represented the same way
2 (Major) . 5 (Minor) . 4 (Patch)
Patch
The patch number should be incremented when (say) a bug is fixed or some other work (refactoring?) has taken place that neither breaks APIs or adds features to the software.
Minor
Developers increment the minor version number when features are added to the software by APIs are not broken.
Major
Developers increment the major version number when public APIs of the software are changes. Major versions can (and often do) feature breaking changes.
Understanding the consequences
If you are using third-party dependencies you should be able to specify the version of that software that you are using. In order to do so you could specify the whole version — say 2.5.1 — and never update from there.
This may seem sensible as it means that your software will never break using that verison of your dependency. However there are real problems with doing this — namely, what if the developer makes some important bug fixes?
So perhaps you wish to just have your version of the software match in-step the version that the developer of the dependency has released. The problem with this is that they might release a new *major* version of the software that could break your software — since the API has changed (potentially) this might take some time to fix — and worse it might happen at any time (as you aren’t in control of the releases of the dependency.
You might have (then) guessed that there is one potential solution for this problem. Yes, you guessed it; you are safe updating the minor version but not the…
