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?

yannis
  • 39,647
Jiew Meng
  • 2,271

6 Answers6

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.
Henry
  • 2,020
6

Major.Minor.Revision.Build

Jeremy
  • 4,597
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.

Rook
  • 19,947
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.

gavenkoa
  • 271
  • 2
  • 10
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

Michael Shaw
  • 10,114
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.

sashang
  • 1,116