68

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

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

4

4 回答 4

34

我认为混乱来自大多数人认为的“修订”以及微软所做的事情：

  • 构建：内部版本号的差异表示对相同源的重新编译。由于处理器、平台或编译器的变化，这将是合适的。

  • 修订版：具有相同名称、主要和次要版本号但不同修订版的程序集旨在完全互换。这适用于修复先前发布的程序集中的安全漏洞。

安全修复角度，可能对他们来说更常见，似乎是把它放在最后的一个正当理由，因为“最轻微的”变化。

于 2010-06-23T00:37:56.937 回答
28

我意识到我来晚了，但我想分享我的两便士，为什么构建和修订的顺序是“错误的”。与其说它们的顺序错误，不如说它们没有任何顺序。

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

Build代表对同一源代码的重新编译。Revision表示代码更改，但可以与相同 [Major.Minor] 版本的其他修订完全互换。但两者都不优先于另一个。

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

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

但反而：

+ Major
|
+-+ Minor
  |
  +-+ Build
  |
  +-+ Revision
于 2013-06-25T14:06:10.370 回答
15

微软是否甚至以这种随意的方式使用数字，例如 3.5.3858.2

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

几乎每个人（包括我）似乎都同意修订属于第三位，而“构建”或任何你想称之为的东西都属于最后。

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

于 2010-06-23T00:57:36.853 回答
2

迟到的答案，但我觉得其他答案可以扩大一点。

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

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

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

    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.

于 2018-04-10T18:30:58.060 回答