Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by MichaelT, GlenH7, Jalayn, Yusubov, gnat Apr 28 '13 at 1:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Not at all. He's asking how the version number is incremented, not the format. –  BryanH Dec 2 '10 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 Dec 8 '10 at 17:43
add comment

6 Answers 6

up vote 8 down vote accepted

Major.Minor.Revision

  • 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.
share|improve this answer
add comment

Major.Minor.Revision.Build

share|improve this answer
    
In my case Revision comes from subversion and build from TeamCity (my CI server). All splatted into place automagically by the build scripts. –  Murph Dec 2 '10 at 9:27
2  
Can you please explain why? –  Dynamic May 12 '12 at 18:07
add comment

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.Y.Z.WWWW

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
    
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 Dec 2 '10 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 Dec 2 '10 at 8:28
add comment

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:

http://www106.pair.com/rhp/parallel.html

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!!

share|improve this answer
add comment

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