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

Jak*_*les 65 .net version version-numbering

为什么.NET中的System.Version定义为Major.Minor.Build.Revision?几乎每个人(包括我)似乎都同意修改属于第三位,而"构建"或任何你想称之为属于最后的版本.

微软是否以这种偶然的方式使用这些数字,例如3.5.3858.2,或者这些名称本身只是倒退?例如,如果您使用订单Major.Minor.Build.Revision编写自己的Version类,在转换为System.Version时交换最后两个组件是否合适,或者忽略它并只是假装名称倒退了吗?

Nic*_*ver 31

我认为最混淆的是大多数人认为是"修订版"以及微软所做的事情:

  • 构建:构建号的差异表示对同一源的重新编译.由于处理器,平台或编译器的更改,这是合适的.

  • 版本:具有相同名称,主要版本号和次要版本号但不同版本的程序集应完全可互换.这适用于修复先前发布的组件中的安全漏洞.

对于他们而言,安全修复角度可能更常见,似乎是将其置于最后位置的一个正当理由,作为"最轻微"的变化.


小智 24

我意识到我来晚会的时间有点晚了,但我想分享一下为什么构建和修改的顺序"错误".并不是说他们的顺序错误,而是他们没有任何顺序.

当它归结为它时,程序集的版本是Major.Minor.微软表示,从前面提到的链接 "只有构建版本或版本号不同的程序集的后续版本被认为是以前版本的修补程序更新." [我的重点]

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

因此,总而言之,不要将其视为:

+ Major
|
+-+ Minor
  |
  +-+ Build
    |
    +-+ Revision
Run Code Online (Sandbox Code Playgroud)

但反而:

+ Major
|
+-+ Minor
  |
  +-+ Build
  |
  +-+ Revision
Run Code Online (Sandbox Code Playgroud)


Chr*_*isW 14

微软是否以这种随意的方式使用这些数字,例如3.5.3858.2

如果你让它默认,例如通过指定[assembly: AssemblyVersion("1.1.*")],则第三个数字每天递增,第四个数字是自午夜以来的秒数除以2(以消除一天内是否有多个版本的歧义).

几乎每个人(包括我)似乎都同意修改属于第三位,而"构建"或任何你想称之为属于最后的版本.

微软似乎正在使用"构建"作为"日"的同义词:也许这与"每日构建"的概念有关; 因此,"修订版"是(每日)构建的另一个版本.

  • 修订号不是随机的.它是午夜以来的秒数除以2. (7认同)