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?

  • Not at all. He's asking how the version number is incremented, not the format.
    – BryanH
    Commented Dec 2, 2010 at 16:34
  • Just giving the format is useless if you don't explain the meaning of its components. Furthermore, in the link I gave, the question is also about "how to increment".
    – barjak
    Commented Dec 8, 2010 at 17:43

6 Answers 6



  • Major. Big change, new features, breaks compatibility, stuff you want to charge extra for.
  • Minor. New features that you can give away. Doesn't break stuff.
  • Revision. Bug fixes.
  • Also note that it is also known as "semantic versionning" and have a complete description there: semver.org
    – Klaim
    Commented Jan 7, 2015 at 18:36


  • In my case Revision comes from subversion and build from TeamCity (my CI server). All splatted into place automagically by the build scripts.
    – Murph
    Commented Dec 2, 2010 at 9:27
  • 2
    Can you please explain why?
    – Dynamic
    Commented May 12, 2012 at 18:07

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 (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.

  • Sounds complicated........
    – Pacerier
    Commented Jan 7, 2015 at 7:11

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


Generally it's a Major.minor.revision number. The major and minor number are choosen by the marketing types to reflect the awesomeness or lack of awesomeness in the new release. The revision number is dictated by the version control system.

  • Hmm, then brings the question on when do you commit to version control, generally after every new feature/bunch of bugfixes?. I always seem to forget. only remembering after too many features/changes have been made ...
    – Jiew Meng
    Commented Dec 2, 2010 at 4:06
  • 2
    @jiewmeng: It's generally good practice is to commit frequently as long as you don't break the build. This means that you won't be out of sync with other developer's changes in the main development branch. Also the host machine running the version control system is backed up, unlike the typical developer's machine.
    – sashang
    Commented Dec 2, 2010 at 8:28

Not the answer you're looking for? Browse other questions tagged or ask your own question.