Do you know semantic versioning? You should! It describes how to name version numbers. Check it out here: semver.org.
This is the pattern it describes:
MAJOR.MINOR.PATCH
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner
PATCH version when you make backwards-compatible bug fixes
The cool thing here is that on the version number itself you can already see how big the changes are in the new release. A typical semantic version number is this:
3.2.1
Let’s say I am using version “3.2.0” in my project. Now I can immediately see that the new version of the package “only” contains a patch. That means for me that I can update without worrying. On the other side if this version comes out:
4.0.0
And I am using version “3.2.1” of the package in my project, I can now immediately see that this update will very likely break my build! In this case I have to look into the change logs and follow the migration paths.
Semantic versioning even addresses alpha and beta versions. If you are working on version “4.0.0” but it’s not quiet ready but you wanna release anyway something, you can name it like this:
4.0.0-a
That means that is version “4.0.0” alpha. And this here would be the beta version:
4.0.0-b
Another convention is “RC”, that means “Release Candidate”. You can use it like this:
4.0.0-RC1 4.0.0-RC2
The complete order over all of them is like this, the highest and newest version is on the top.
4.0.0 4.0.0-RC2 4.0.0-RC1 4.0.0-b 4.0.0-a
That basically means 4.0.0 > 4.0.0-RC2 > 4.0.0-RC1 > 4.0.0-b > 4.0.0-a.
I’m the author of naturalsorter. That is an open source library to sort semantic version numbers in the correct way.
Robert Reiz 