Semantic Versioning

Semantic versioning is a simple versioning scheme suggested by OSGi Alliance where it conveys much more meaning about what’s changing than normal versioning schemes do.

Following are the key points:

• Every version consists of four parts: major, minor, micro, and qualifier (Major.Minor.Micro.Qualifier).
  
• A change to the major part of a version number (for example, changing 2.0.0.0 to 3.0.0.0) indicates that the code change isn’t backwards compatible. Removing a method or changing its argument types is an example of this kind of breaking change.
  
• A change to the minor part (for e.g., changing 2.0.0.0 to 2.1.0.0) indicates a change that is backwards compatible for consumers of an API, but not for implementation providers. For example, the minor version should be incremented if a method is added to an interface in the API, because this will require changes to implementations.
  
• If a change doesn’t affect the externals at all, it should be indicated by a change to the micro version (for e.g., changing 2.0.0.0 to 2.0.1.0). Such a change could be a bug fix, or a performance improvement, or even some internal changes that remove a private method from an API class. Having a strong division between bundle internals and bundle externals means the internals can be changed dramatically without anything other than the micro version of the bundle needing to change.
  
• Finally, the qualifier is used to add extra information, such as a build date (for e.g. changing 2.0.0.0 to 2.0.0.110813, 110813 represents 08-Nov-2013) .

Among the version sections defined above, many of the product/component writers prefer Major, Minor and Micro and in some cases even Micro is left back and just add to your general knowledge Google does not follow any (WTH!!). So, its up to you as how you take it. For me, i love it.