Build numbers in sync across many tools or not?

We currently have many office products and a embedded product. They all have the same version scheme major.minor.build number.svn revision. With nightly and manual builds incrementing the build number.

From a development support front this makes it really easy to manage 'correct version', but the in-field support guys panic when one tool changes from v10 to v200 and we say there's no changes.

Are there any problems with this scheme (all in sync) that we are missing due to our love for it?

Update: It's the build number that is increasing by leaps, the major minor are only changed on a yearly type scale.

the svn revision is the same for all files at time x, but the nobody really pays that attention.

All .exe's and .dll's etc have the same X.Y.W.Z number. So the office product go from 1.1.10.1234 to 1.1.132.4321 when we do lots of work on the embedded product.

From stackoverflow

• I wouldn't really say this is an issue as long as they can easily look up the change log to see whats changed.

  Logically thinking though, if no libraries have been updated in any of the products, nor have there been any changes to the product itself the version number should stay the same.

  The only suggestion I could make is moving to a dated version number so that the major and minor versions don't change so rapidly. Something like 9.0417.yyyy.xxxx would be the 17th of April 2009 release with the build number of yyyy and xxxx as the svn revision. If you don't want to change the major number and want to keep the date in the minor you could use Microsoft's versioning style. There's a good blog article on how Microsoft do their versioning at http://blogs.msdn.com/jensenh/archive/2005/11/11/491779.aspx.

• I've used an aggregate versioning scheme. So you say you have many products that each share the same revision number if the deployed field versions - I'm assuming this means if you update your embedded libraries, that the office products do not use the libraries for, the office products still get a new revision number, even though no code has changed in them.

  So in an aggregate scheme, the SYSTEM has one big version number, and each sub system has their own. I'm using clearcase notation because I don't know the terminology for the equivelant in svn: The top level component has all sub components under it in a hiearchy (think of a component is like a folder with code in it such that everything in that folder shared the same version, or "baseline", as clearcase calls it).

  If I make a new baseline (version) in a top level system component, it tags it with the new version, and all sub components get a new version also (possibly with a different versioning scheme), but only if they've changed.

  We use a date-time baseline, and a "release number", for the top level system version. Then, each sub system has the major/minor/build/svn in it. Also, we don't show the svn and build number in the "about->help" or equivelant, only if you go deep into some "system config" file can you pull out the actual build/svn number (like, by looking at the meta data in the executble). That way, users only see major/minor version, and not the gobbledigook of build and svn numbers.