What's the point of having the build number in the .NET framework versions?

Question

The .NET Framework CLR files are located in the following folders under C:\Windows\Microsoft.NET\Framework:

v1.0.3705
v1.1.4322
v2.0.50727
v4.0.30319

(Yes, there's v3.0 and v3.5 as well, but they contain only additional libraries, not the CLR.)

Note that the framework versions .NET 4.0, 4.5, 4.5.1, 4.5.2, 4.6 and 4.6.1 are all stored in the v4.0.30319 folder. Obviously, since they are all upgrades to 4.0, this makes sense from a backwards-compatibility point of view.

In that case, what's the point of calling it v4.0.30319 instead of v4.0 or, more appropriately, v4? Isn't the point of a build number to provide an additional layer of versioning within a minor version?

The same was done with 3.0 and 3.5, which were upgrades to 2.0, so it's not like they didn't know that the build (and even the minor) number is going to change through updates. They did it again for v4, so there must be some good reason for it.

Answer 1

Microsoft is probably the best "person" to ask this. If you expect some rhyme or reason to their versioning scheme, you're not going to find much on the Internet; they've changed their numbering scheme at least once.

However... It appears that the build number is part of a strategy of allowing the version to be encoded in a single DWORD in the registry, and I'll note that the build number (assuming you already know the version number) is the only way to track patches and updates to a minor version in .NET 4 (since microsoft eliminated the "patch" number from their numbering scheme in .NET 4).

I would also note that the build number is the easiest thing to use for this purpose. It is generated automatically (probably from their CI servers), so making a properly-versioned patch is painless.