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

Solution 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.

Solution 2:

I realize I'm coming to the party a bit late, but I wanted to share my twopence on why the order of build and revision are "wrong." It's not so much that they're in the wrong order, but that they're not in any order.

The version of an assembly, when it comes down to it, is Major.Minor. From the aforementioned link, Microsoft says, "Subsequent versions of an assembly that differ only by build or revision numbers are considered to be Hotfix updates of the prior version." [My emphasis]

The Build represents a recompilation of the same source. The Revision represents a code change, but one that is fully interchangable with other revisions of the same [Major.Minor] version. But neither takes precedence over the other.

So, in summary, don't think of it as:

+ Major
|
+-+ Minor
  |
  +-+ Build
    |
    +-+ Revision

But instead:

+ Major
|
+-+ Minor
  |
  +-+ Build
  |
  +-+ Revision

Solution 3:

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 the number of seconds since midnight, divided by two (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.

Solution 4:

Late answer, but I feel the other answers could be expanded on a bit.

The terms "build" and "revision" is just Microsoft terminology. The System.Version class does not care in any way how you assign them.

As for switching the order of parts to match your own terminology i would say that you should basically ignore the words entirely and instead consider what the System.Version really defines:

• A string format that it can parse and generate:

  major.minor[.build[.revision]]
  

  This means that if you are used to having you own version formatted as x.y.z.w, then you should instantiate the Version class this way:

  new Version(x, y, z, w)
  

  Any other parameter order will not match what Parse() and ToString() would do. If you switch z and w, then ToString() would output x.y.w.z which would be confusing for everyone if you expect x.y.z.w.

• A version comparison and sort order, whereby versions are sorted first by major, then by minor, then build, then revision, as most of us would expect. That is, 1.2.5 is later than 1.2.3.7.

  So if you style your version string as 1.2.6.4 and want that to be considered newer than 1.2.5.8, then do not switch the order of the parts in the Version constructor.

In short - while the words major/minor/build/revision might give a clue as to which number should be increased considering the amount of changes, the terminology have very little impact on how the class is actually used. Formatting and sorting is what matters.