The version number itself, and more generally the way you manage it, is most of the time underestimated because it’s considered something trivial.
It is used to give a chronological order to the software releases and it conveys the useful information about the state and the impact of the release.
I can think only of two major way to assign a version number:
Obviously there are several ways of customising those to your own needs, and you can find everywhere different, non-standard, version numbers every day being used.
But, personally, I prefer the following structure and I’d recommend it to everyone:
The rules are quite straight-forward:
MAJORwhen releasing something that is NOT backward compatible
MINORwhen releasing something that is backward compatible
PATCHwhen releasing a bug fix (obvs backwards compatible)
- the stability follows this order:
Usually, I never bother to use
betabecause they are so unstable and so frequently updated that it’s not worth the time to create a tag and release it, I’d rather release a
I also found out that there is even a manifesto for the versioning scheme I’m using and promoting.
However, this is not preventing you anyhow to assign to your release a codename.
This could be a solution to avoid problems when deciding which version to use, recognising at first glance if the release is stable or not, and especially be aware whether it’s backwards-compatible.
Still, do not ever trust blindly an external dependency.