Version number has four parts:
Major part . Minor part :-A new Major or Minor part indicates that the new version is incompatible with the old one. For example, version 126.96.36.199 should be incompatible with version 188.8.131.52.
You should change major version numbers whenever you introduce an incompatibility into your code.
Major part involves a total rewrite or rearchitecting of a software product.
Changes in language, major changes in design, and changes in platform fall into this category. This number starts at 1 (one).
Build part:-A new build part indicates probable compatibility.
Typically you should change minor version numbers when you introduce a service pack or a minor upgrade.
For example, version 184.108.40.206 is probably compatible with version 220.127.116.11.
Minor part involves additions in features that require changes in documentation/external API. This number starts at 0 (zero).
Revision part:-A new revision part indicates a QFE (Quick Fix Engineering) release that is compatible with the previous version and that should be installed. For example, version 18.104.22.168 might be a mandatory bug-fix upgrade to version 22.214.171.124.
This is any change that doesn't require documentation/external API changes. This number starts at 0 (zero).
Setting the Version attribute to "1.0.*" tells use 1 for the major part, 0 for the minor part, and to come up with build and revision part numbers automatically. You can also specify all four parts of the version number explicitly:
All version numbering is based on external view. Meaning, this is a number scheme that intended to reflect the release of a product, not the internal production. Thus, recompilation does not effect the version number.
The terms "alpha" and "beta" shall not be used in the version number.
These terms reflect little these days and aren't qualitative (i.e. "1.0.0" sorts before "1.0.0 alpha", but should sort after).