6

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?

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

6 Answers 6

Reset to default
10

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.
Improve this answer
1
  • Also note that it is also known as "semantic versionning" and have a complete description there: semver.org
    – Klaim
    Jan 7, 2015 at 18:36
6

Major.Minor.Revision.Build

Improve this answer
2
  • 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, 2010 at 9:27
  • 2
    Can you please explain why?
    – Dynamic
    May 12, 2012 at 18:07
4

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.

Improve this answer
1

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

UPDATE For those who fill yourself as hipster - http://semver.org/ - like in libtool docs but shine as Web 2.0.

Improve this answer
1
  • Sounds complicated........
    – Pacerier
    Jan 7, 2015 at 7:11
0

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

Improve this answer
0

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.

Improve this answer
2
  • 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, 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
    Dec 2, 2010 at 8:28

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