My question is, which version-naming scheme should be used for what type of project.
Very common is major.minor.fix, but even this can lead to 4 number (i.e. Firefox 2.0.0.16). Some have a model that odd numbers indicate developer-versions and even numbers stable releases. And all sorts of additions can enter the mix, like -dev3, -rc1, SP2 etc.
Exists reasons to prefer one scheme over another and should different type of projects (i.e. Open Source vs. Closed Source) have different version naming schemes?
Modern computer software is often tracked using two different software versioning schemes: an internal version number that may be incremented many times in a single day, such as a revision control number, and a release version that typically changes far less often, such as semantic versioning or a project code name.
A version number is a unique number or set of numbers assigned to a specific release of a software program, file, firmware, device driver, or even hardware. Typically, as updates and entirely new editions of a program or driver are released, the version number will increase.
There are two good answers for this (plus a lot of personal preferences; see gizmo's comment on religious wars).
For public applications, the standard Major.Minor.Revision.Build
works best IMO - public users can easily tell what version of the program they have and, to some degree, how far out of date their version is.
For in house applications, where the users never asked for the application, the deployment is handled by IT, and users will be calling the help desk, I found the Year.Month.Day.Build
to work better in a lot of situations. This version number can thus be decoded to provide more useful information to the help desk than the public versioning number scheme.
However at the end of the day I would make one recommendation above all else - use a system you can keep consistent. If there is a system that you can setup/script your compiler to automatically use everytime, use that.
The worst thing that can happen is you releasing binaries with the same version number as the previous ones - I've recently been dealing with automated network error reports (someone elses application), and came to the conclusion that the Year.Month.Day.Build version numbers shown in the core dumps where not even remotely up to date with the application itself (the application itself used a splash screen with the real numbers - which of course where not drawn from the binary as one might assume). The result is I have no way of knowing if crash dumps are coming from a 2 year old binary (what the version number indicates) or a 2 month old binary, and thus no way of getting the right source code (no source control either!)
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