Why is System.Version in .NET defined as Major.Minor.Build.Revision?

Question

Why is System.Version in .NET defined as Major.Minor.Build.Revision? Almost everyone (including me) seems to agree that revision belongs in third place, and "build" or whatever you'd like to call it belongs last.

Does Microsoft even use the numbers in this haphazard way, e.g. 3.5.3858.2, or are the names themselves just backwards? For example if you were to write your own Version class with the order Major.Minor.Build.Revision, would it be proper to swap the last two components when converting to a System.Version, or do you ignore it and just pretend the names are backwards?

Answer 1

I think the confusion comes what most consider a "revision" and what Microsoft does:

• Build: A difference in build number represents a recompilation of the same source. This would be appropriate because of processor, platform, or compiler changes.

• Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. This would be appropriate to fix a security hole in a previously released assembly.

The security fix angle, probably much more common for them, seems to be a decent reason to have it in last place, as the "most-minor" change.

Answer 2

Does Microsoft even use the numbers in this haphazard way, e.g. 3.5.3858.2

If you let it default, e.g. by specifying [assembly: AssemblyVersion("1.1.*")], then the third number increments each day, and the fourth number is a random number (to disambiguate if there's more than one builds in a single day).

Almost everyone (including me) seems to agree that revision belongs in third place, and "build" or whatever you'd like to call it belongs last.

Microsoft seem to be using "build" as a synonym of "day": perhaps that's related to the idea of "daily builds"; and a "revision" is then therefore another version of the (daily) build.