.Net AssemblyName.version构建与修订

时间:2010-07-19 07:44:16

标签: c# .net build-process versioning

MSDN文档声明:

  

版本号由2到4组成   组件:主要,次要,构建和   修订。主要和次要的   组件是必需的;构建和   修订组件是可选的,但是   如果是,则需要构建组件   修订组件已定义。所有   定义的组件必须是整数   大于或等于0.

     

版本号的格式为   如下(可选组件显示   在方括号([和])中:   major.minor [.build [.revision]]   组件按惯例使用   如下:

     
      
  • 主要:具有相同名称的程序集   但不同的主要版本不是   互换。更高的版本   数字可能表示重大改写   一个落后的产品   不能假设兼容性。

  •   
  • 轻微:如果名称和专业   两个程序集上的版本号是   相同,但次要版本号   这表明不同   显着增强   向后兼容的意图。   这个较高的次要版本号可能   表示产品的积分释放   或完全向后兼容的新   产品版本。

  •   
  • 构建:内部版本号的差异   表示对它的重新编译   资源。不同的构建数量可能   当处理器,平台,   或编译器更改。

  •   
  • 修订版:具有相同的程序集   名称,主要和次要版本号   但是意图进行不同的修订   完全可以互换。更高   版本号可能用于   用于修复安全漏洞的构建   以前发布的装配。

  •   
     

程序集的后续版本   不同之处仅在于构建或修订   数字被认为是修补程序   更新先前版本。

我的问题是关于此背景下术语构建和修订的含义

在我看来,一般来说,当源头发生变化时,我们会“建立”。因此,“build 678”和“build 679”不同正好因为源在某种程度上是不同的 - 通常是由于检查了一些变化的源。在我看来,.NET定义使用“修订版”的方式通常使用“构建”。

有人在他们的版本控制中使用上面的定义吗?如果是这样,你能举例说明你为什么这么做?

2 个答案:

答案 0 :(得分:22)

  

仅根据构建版本或修订版号不同的程序集的后续版本被视为先前版本的修补程序更新。

本节介绍了区别。您的产品出厂时使用了修订版,并且您在进行更新时需要修复已发布的版本。

例如1.1.10.0船。我正在对功能进行小的更改,当我收到需要修复的安全警报时,我在1.1.20.0。我无法将1.1.10.0增加到1.1.11.0,因为它代表了其他内容。所以我使用1.1.10.1来确定它是1.1.10.0代码的修订版。

希望这比泥土更清晰。还要记住公司的规模和他们发布的软件项目的大小,这些项目提出了这些定义。

答案 1 :(得分:2)

我完全同意你的意见。除非你用一点点盐来解释它们,否则给定的描述并没有多大意义。对我来说,最后一个版本号应该是 build ,即每个编译时更新的数字。其他数字代表软件/ API的不同变化程度。

实际上,这就是版本号通常被使用的方式。 (当然,我如何使用它们。)

  • 专业 - 当软件的功能集/ API发生重大变化时增加

  • 次要 - 在进行了显着更改,次要API更改或添加新功能时增加

  • 构建 - 在进行细微更改时增加,通常是错误修复和改进(虽然没有API更改)

  • 修订版 - 代表构建实例的唯一ID /编号