Some version numbers increase very quickly (like firefox and google chrome) and others don't (like cloudapp and the ubuntu kernel). I'm kinda thinking that the developer chooses how fast the number increments; it'd be silly to add a full +1 to the number if you fixed only minor stuff though....
migrated from stackoverflow.com Sep 18 '11 at 12:17
Wikipedia has a discussion of various version number schemes. It really doesn't matter what scheme you use, and your customers probably don't care. The key is that you can identify the version that is being tested or has been released and have quick access to all associated artifacts for that version.
the whole idea is
One standard I find amazingly useful is the Semantic Versioning Standard at http://semver.org . It's really short, but straightforward and I haven't found an issue yet that it doesn't cover.
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!!
@Ed. I specially state: versioning schema for developer, does not for marketing. I use this rules for developer versioning so restrict unnecessery MAJOR + 1. Usually managers or sellers can decide increment MAJOR and this can break code:
if (vmajor != 3) error("Incompatable version detected!");
Best is separate versioning for marketing and for developers (and maintain both of them).