73

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?

Jake Petroules
  • 23,472
  • 35
  • 144
  • 225

4 Answers4

37

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.

Nick Craver
  • 623,446
  • 136
  • 1,297
  • 1,155
  • That makes sense. But with your own version class using the order major.minor.revision.build, would it be proper to swap the last two components when converting to a .NET `System.Version`? Or leave them alone and let them be called by opposite names in each structure? – Jake Petroules Jun 23 '10 at 01:31
  • 1
    @Jake - Up to each person doing the build I suppose...personally I *do* swap them, my convention is actually `Major.Minor.Revision.ChangeSet`, so I can get the exact code running our of source control just by glancing at the number. Since we do continuous integration, changeset and build number being synonymous for us made sense...not sure that works everywhere though. – Nick Craver Jun 23 '10 at 01:37
31

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
Charlie Hills
  • 636
  • 6
  • 13
  • This explanation makes things less confusing. It was really hard to verify that I have the same .Net revisions installed on different machines. Specifically, the "Revision" number seems to always be different between OS versions, while the Major, Minor, and Build numbers are all the same. E.g. on Windows 8.1, my "...\Framework64\v4.0.30319\clr.dll" is at 4.0.30319.34014, but on a Win2k8 r1 server, the file is at 4.0.30319.18444. – Granger Dec 01 '14 at 20:46
  • I find this answer better as the accepted answer because I understand better with the tree. Thanks – Nk54 May 18 '20 at 16:01
16

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.

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137
ChrisW
  • 54,973
  • 13
  • 116
  • 224
  • Not really what the question is asking. He's not asking what they are, but why are they are in this particular order. – Alastair Pitts Jun 23 '10 at 01:01
  • @Alastair Pitts - I've added to my answer to try to address that. – ChrisW Jun 23 '10 at 01:08
  • 7
    The revision number isn't random. It's the number of seconds since midnight, divided by two. – Daniel Dec 19 '12 at 00:06
  • Thank you for this view! So "major.minor.day.second" makes sense and answers the question "Why is System.Version in .NET defined as Major.Minor.Build.Revision?" – hfrmobile Jan 10 '17 at 10:55
  • The docs say 'build' is recompilation of the same source. It's literally what the word means... it's the action of building. Not until 'revision' do you have a source change. The fact that it automatically uses the build as day and revision as seconds since midnight just makes the situation even more maddening. – DAG Apr 11 '23 at 14:30
3

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.

Oskar Berggren
  • 5,583
  • 1
  • 19
  • 36