为什么.NET中的System.Version定义为Major.Minor.Build.Revision？几乎每个人（包括我）似乎都同意修订属于第三名，而“构建”或任何你想称之为属于最后的版本。
Microsoft是否以这种随意的方式使用这些数字，例如3.5.3858.2，或名称本身只是向后？例如，如果您使用订单Major.Minor.Build.Revision编写自己的Version类，在转换为System.Version时交换最后两个组件是否合适，或者忽略它并只是假装名称倒退了？
答案 0 :(得分：31)
我认为最混淆的是大多数人认为是“修订版”和what Microsoft does：
构建：构建号的差异表示对同一源的重新编译。由于处理器，平台或编译器的更改，这是合适的。
修订版：具有相同名称，主要版本号和次要版本号但不同修订版的程序集应完全可互换。这适用于在先前发布的组件中修复安全漏洞。
对于他们而言，安全修正角度可能更为常见，似乎是将其置于最后一个位置的正当理由，作为“最轻微”的变化。
答案 1 :(得分：24)
我意识到我来晚会的时间有点晚了，但我想分享一下为什么构建和修改的顺序“错误”。并不是因为他们处于错误的顺序，而是他们不是任何顺序。
当它归结为它时，程序集的版本是Major.Minor。微软表示，从前面提到的link开始，“仅根据版本号或版本号不同的程序集的后续版本被视为先前版本的修补程序更新。” [我的重点]
Build 表示对同一源代码的重新编译。 Revision 表示代码更改，但可以与同一[Major.Minor]版本的其他修订完全互换。但两者都不优先于另一个。
因此，总而言之，不要将其视为：
+ Major
|
+-+ Minor
|
+-+ Build
|
+-+ Revision
但相反：
+ Major
|
+-+ Minor
|
+-+ Build
|
+-+ Revision
答案 2 :(得分：13)
Microsoft是否以这种随意的方式使用这些数字，例如3.5.3858.2
如果您将其设为默认值，例如通过指定[assembly: AssemblyVersion("1.1.*")]，
然后第三个数字每天递增，第四个数字是自午夜以来的秒数除以2（以消除一天内是否有多个构建的歧义）。
几乎每个人（包括我）似乎都同意修订属于第三名，而“构建”或任何你想称之为属于最后的版本。
微软似乎正在使用“build”作为“day”的同义词：也许这与“daily builds”的概念有关;因此，“修订版”是（每日）构建的另一个版本。
答案 3 :(得分：1)
迟到的答案，但我觉得其他答案可以稍微扩展一下。
条款＆＃34; build＆＃34;和＆＃34;修订＆＃34;只是微软的术语。 System.Version类并不关心您如何分配它们。
至于切换部件的顺序以匹配您自己的术语，我会说您应该完全忽略这些单词，而是考虑System.Version 真正定义的内容：
可以解析并生成的字符串格式：
major.minor[.build[.revision]]
这意味着如果您习惯将自己的版本格式化为 x.y.z.w，那么你应该用这种方式实例化Version类：
new Version(x, y, z, w)
任何其他参数顺序与Parse（）和ToString（）不匹配 会做。如果切换z和w，则ToString（）将输出x.y.w.z 如果您期望x.y.z.w。
A version comparison and sort order，对版本进行排序 首先是 主要的，然后是次要的，然后建立，然后修改，就像我们大多数人一样 期望。也就是说，1.2.5晚于1.2.3.7。
因此，如果您将版本字符串设置为1.2.6.4并希望如此 考虑比1.2.5.8更新，然后不要切换部件的顺序 版本构造函数。
简而言之 - 虽然主要/次要/构建/修订这两个词可能会给出一个关于应该根据变化量增加哪个数字的线索，但术语对于实际使用该类的方式影响很小。格式化和排序是最重要的。