Confusion between Build and Revision numbers

[BoscoC]

According to the Microsoft Visual Studio.NET documentation...

"Remarks:
The format of the version string is: major. minor. build. revision"

However, when I configure Visual Build Pro to automatically increment the BUILD number, it's the REVISION number that's incremented, and vice versa.

This is a bug in Visual Build Pro, right? This is a section from the VBP documentation, which seems to contradict the MS documentation...

"Normally, the Build version number (4th number) is incremented, but the Revision number (3rd number) can be incremented instead by checking that checkbox"

Please advise.

[pjaquiery]

For my money Kinook have it right. Common usage is that the 4th number is a build number. For our products we use it as a "stage" by using numbers in the range 0-255 as development builds, 256-511 alpha, and so on.

We put the compile time and date into the version resource so that we don't bump a build number for each build. A time and date is MUCH more useful than a number that provides no extra information.

We use VBP to create a header file containing a #define for the time and date that is used wherever we want a consistent time stamp for the build. The version of the header used on developers machines provides a string saying that the build is unofficial: we only generate "official" build on the build machine.

[kinook]

Pre .NET, it's difficult to find a definitive naming of these version fields (if anybody has some precedent on that it would be helpful as this affects the Make VC6 action as well), but in the .NET era Microsoft seems to have changed their mind on their naming. These search hits provide some insight into this issue: http://groups.google.com/groups?hl=e...ld&sa=N&tab=wg

If you follow the first thread, it comes down to this: The ECMA standard (which Microsoft submitted parts of .NET to) says major.minor.revision.build. MSDN (generally) says major.minor.build.revision.

Since the current VS.NET documentation has major.minor.build.revision, I can see an argument for changing VBP to match that, and we'll consider doing that (or maybe we'll just call them field 3 and 4 :^). For now, the important thing is that, whatever you decide to call them, you can increment either field from VBP.