Software Versions Explained

Whenever you see software updates, like when you have to update your OS on your phone and it keeps reminding you, there are usually three numbers in there, and sometimes more things tacked on. This is called Semantic Versioning, and it is key to keeping things cohesive in software.

Semantic Versioning is the process in which version number increments are determined. There are 3 things one can change that affect a version, a major overhaul change, a minor functionality change, and a patch with bug fixes, etc. When changing anything regarding what packages you integrate, you have to assure compatibility with other systems when publishing a new version and determine what version of the dependencies are compatible with the updated release version. You don’t want to end up in a “version lock” trap where there is no ability to upgrade a package without having to release new versions of every dependent package, while at the same time you don’t want to be too loose assuming compatibility otherwise you’ll end up in “dependency hell.” In a version format with X.Y.Z, Bug fixes not affecting the API are .Z, backward compatible API additions/changes increment .Y, and backward-incompatible API changes increment the .X version; all with no leading zeros, an API defined, and nothing ever modified after declaration. V1.0.0 is the first public version, pre-release versions add a hyphen using another x.y.z series, and build metadata is denoted by using a plus sign followed by another set of x.y.z with this being the last set of x.y.z possible. Precedence must also be considered by separating the version into major, minor, patch pre-release x.y.z identifiers in that order, with build metadata not being factored into precedence. Managing this and documenting changes is very important to help keep a project efficient, and Semantic Versioning alongside a well-defined API will keep everything coherent.