为什么 .NET 中的 System.Version 被定义为 Major.Minor.Build.Revision？

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

提问by Jake Petroules

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.

为什么 .NET 中的 System.Version 被定义为 Major.Minor.Build.Revision？几乎每个人（包括我）似乎都同意修订属于第三位，而“构建”或您想称之为的任何东西属于最后。

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?

Microsoft 甚至以这种随意的方式使用数字，例如 3.5.3858.2，还是名称本身只是倒退？例如，如果您要使用 Major.Minor.Build.Revision 的顺序编写自己的 Version 类，那么在转换为 System.Version 时交换最后两个组件是否合适，还是忽略它并假装名称是落后？

采纳答案by Nick Craver

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.

安全修复角度对他们来说可能更常见，似乎是将它放在最后的一个不错的理由，因为“最次要”的变化。

回答by Charlie Hills

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 wrongorder, but that they're not in anyorder.

我意识到我参加聚会有点晚了，但我想分享我的两便士为什么构建和修订的顺序是“错误的”。并不是说它们的顺序错误，而是它们没有任何顺序。

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]

归根结底，程序集的版本是 Major.Minor。从上述链接中，微软表示，“仅在版本号或修订号上有所不同的程序集的后续版本被认为是先前版本的修补程序更新。” 【我的重点】

The Buildrepresents a recompilation of the same source. The Revisionrepresents 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.

在构建代表相同源的重新编译。的修订表示代码的变化，而且是一个具有相同的[MAJOR.MINOR]版本其他版本完全互换。但两者都不优先于另一个。

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

因此，总而言之，不要将其视为：

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

But instead:

但反而：

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

回答by ChrisW

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

微软是否甚至以这种随意的方式使用数字，例如 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).

如果您让它默认，例如通过指定[assembly: AssemblyVersion("1.1.*")]，那么第三个数字每天递增，第四个数字是自午夜以来的秒数除以 2（以消除一天中多个构建的歧义）。

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.

微软似乎将“build”用作“day”的同义词：也许这与“daily builds”的想法有关；因此，“修订版”是（每日）构建的另一个版本。

回答by Oskar Berggren

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.

术语“构建”和“修订”只是微软的术语。System.Version 类不关心您如何分配它们。

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 reallydefines:

至于切换部分的顺序以匹配您自己的术语，我会说您基本上应该完全忽略这些词，而是考虑 System.Version真正定义的内容：

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

• 它可以解析和生成的字符串格式：

  major.minor[.build[.revision]]
  

  这意味着，如果您习惯于将自己的版本格式化为 xyzw，那么您应该以这种方式实例化 Version 类：

  new Version(x, y, z, w)
  

  任何其他参数顺序都不会匹配 Parse() 和 ToString() 会做什么。如果你切换 z 和 w，那么 ToString() 将输出 xywz 如果你期望 xyzw 这会让每个人都感到困惑

• 一个版本比较和排序，从而版本由专业，然后通过轻微的，然后再建，再修改第一排序，因为我们大多数人期望的那样。也就是说，1.2.5 晚于 1.2.3.7。

  因此，如果您将版本字符串的样式设置为 1.2.6.4 并希望将其视为比 1.2.5.8 新，则不要在 Version 构造函数中切换各部分的顺序。

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.

简而言之——虽然主要/次要/构建/修订这两个词可能会提供一个线索，考虑到变化的数量应该增加哪个数量，但术语对类的实际使用方式几乎没有影响。格式化和排序很重要。