views:

48

answers:

2

I know the standard Major.Minor.Build.Revision but there's several considerations for us that are somewhat unique

-We do internal releases almost daily, occasionally more than once a day.

-Windows Installer doesn't check Revision so that's almost moot for our purposes.

-Major and Minor numbers ideally are only updated for public releases and should be done manually.

-That leaves the Build # that needs to be automatically updated.

-We want internal releases to be able to be performed from any developer's machine so that leaves out using x.x.* in Visual Studio because different numbers could be generated from different machines and each build isn't guaranteed to be larger than the previous.

-We have about 15 or so projects as part of the product so saving the version numbers in SVN isn't ideal since every release we'd have commit all those files.

Given those criteria I can't really come up with a good versioning scheme. The last 2 criteria could be dropped but meeting all of those seems ideal. A date stamp is insufficient because we might do more than one a day, and given the max size of Uint16 (around 64000) (Actually using WiX it complains about numbers higher than Int16.MaxValue) a date/time won't fit.

+1  A: 
  1. Use SVN commit numbers, or other commit IDs (we usually use git describe output, which is perfect in most cases). Builds should be traceable - its important to only build from committed sources if you want to actually be able to determine what you are running.
  2. Use the time/date in second precision (UNIX epoch time). This will work for you until 2038. If the number is too big, use a different epoch (such as the year 2000).

Also, Uint32 is not limited to 2^16 (65535), its 32 bit giving you 2^32, or roughly 4 billion.

Yann Ramin
My mistake, it was ushort and short instead of UInt and Int32.
Davy8
But I suppose commit number works. We haven't broke 10k yet in several years so we should be good for a while.
Davy8
+1  A: 

Since msi doesn't check revisions, we switched the third and fourth version part in our build system for the msi.

For example, if the real version is 1.2.3.4678 (the 4678 is the SVN revision the app is built from), we create the msi version as 1.2.4678.3.

Stefan