Menu
First Number: Tracks major changes. Second Number: Tracks minor changes. Third Number: Tracks patches or mere bug fixes. Fourth Number: Tracks changes less significant than a patch.
In general, a software version is a set of two to four numbers clubbed together and separated by periods or “.”. Depending on the software type, each set indicates a different set of information about the updates or changes made to the software (continue reading to find more).
There are simple rules that indicate when you must increment each of these versions: MAJOR is incremented when you make breaking API changes. MINOR is incremented when you add new functionality without breaking the existing API or functionality. PATCH is incremented when you make backwards-compatible bug fixes.
The usual method I have seen is X.Y.Z, which generally corresponds to major.minor.patch:
Other variations use build numbers as an additional identifier. So you may have a large number for X.Y.Z.build if you have many revisions that are tested between releases. I use a couple of packages that are identified by year/month or year/release. Thus, a release in the month of September of 2010 might be 2010.9 or 2010.3 for the 3rd release of this year.
There are many variants to versioning. It all boils down to personal preference.
For the "1.3v1.1", that may be two different internal products, something that would be a shared library / codebase that is rev'd differently from the main product; that may indicate version 1.3 for the main product, and version 1.1 of the internal library / package.
You might find the Semantic Versioning Specification useful.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With