I wonder how do you decide on the version number of your apps, do you really record down all changes made (for a change log)? Then how will you decide how to increment the version number. eg. +0.0.1 for each bug fix or something, +0.1 for each new feature release? or maybe you bundle many changes into +0.1 of your version number?
Although this has changed through the years (I've worked on several projects which each used different versioning schemes), it has always been something like this:
the major version, the minor version, and the update version
X: major release with identifiable new features
Y: minor release with existing feature improvements
Z: update release (distributed) containing bug fixes but no new functionality
W: code build - internal to programmers
These program version numbers did not necessarily correspond to the numbers used by marketing. What I mean? For example, Word 2000 (communicated to the public) is really Word 22.214.171.12421 (internal to the product team). Product marketing owns the name that's distributed; Development owns versioning and the project code name.
Numbering schemes are largely irrelevant to customers; versioning is only for keeping track of what is shipping to the customer. There are many software developers who think that numbering schemes are a not-important marketing aspect of the product. Marketing people and customers generally do not (or should not) care about version numbers.
After reading a lot of articles/QAs/FAQs/books I become to think that [MAJOR].[MINOR].[REV] is most useful versioning schema to describe compatibility between project version (versioning schema for developer, does not for marketing).
MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.
MINOR changes is backward compatible. Mark introduction of new features.
REV for security/bug fixes. Backward and forward compatible.
This versioning schema inspired by libtool versioning semantics and by articles:
NOTE: I also recommend provide build/date/custom/quality as additional info (build number, build date, customer name, release quality):
Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545
But this info is not versioning info!!
UPDATE For those who fill yourself as hipster - http://semver.org/ - like in
libtool docs but shine as Web 2.0.
Making this change by hand will result in customers having different versions of your DLL's with the same version number. the only safe way I know is to use the Build server to do this automatically. The build server will add a 0.0.1 each time the code is built.
As far as I am concerned the 0.1 and 1. changes occur when you make release branches, keeping the trunk development as 0.0.0.x