.Net AssemblyName.version构建与修订
MSDN文档说明：
版本号由两到四个组件组成：主要，次要，构建和修订。 主要和次要组件是必需的; 构建和修订组件是可选的，但如果定义了修订组件，则需要构建组件。 所有已定义的组件必须是大于或等于0的整数。
版本号的格式如下（可选组件显示在方括号（[和]）中：major.minor [.build [.revision]]组件按惯例使用如下：
Major：具有相同名称但主要版本不同的程序集不可互换。 较高的版本号可能表示无法假定向后兼容性的产品的重大重写。
轻微：如果两个程序集上的名称和主要版本号相同，但次要版本号不同，则表示具有向后兼容性的显着增强。 较高的次要版本号可能表示产品的点发布或完全向后兼容的新版本产品。
构建：构建号的差异表示对同一源的重新编译。 当处理器，平台或编译器发生更改时，可能会使用不同的构建号。
版本：具有相同名称，主要版本号和次要版本号但不同版本的程序集应完全可互换。 可以在构建中使用更高版本号来修复先前释放的程序集中的安全漏洞。
仅由构建号或修订号不同的程序集的后续版本被视为先前版本的修补程序更新。
我的问题是关于在这种情况下术语构建和修订的含义 。
在我看来，一般来说，当源头发生变化时，我们会“建立”。 因此，“build 678”和“build 679”之所以不同， 恰恰是因为源在某种程度上是不同的 – 通常是由于检查了一些变化的源。 在我看来，.NET定义使用“修订版”的方式通常使用“构建”。
有人在他们的版本控制中使用上面的定义吗？ 如果是这样，你能举例说明你为什么这样做？
仅由构建号或修订号不同的程序集的后续版本被视为先前版本的修补程序更新。
本节解释了不同之处。 产品发布时使用修订版，并且在您已经进行更新时需要修复已发布的版本。
例如1.1.10.0船。 我正在对function进行小的更改，当我收到需要修复的安全警报时，我在1.1.20.0。 我无法将1.1.10.0增加到1.1.11.0，因为它代表了其他内容。 所以我使用1.1.10.1来确定它是1.1.10.0代码的修订版。
希望这比泥土更清晰。 还要记住公司的规模和他们发布的软件项目的大小，这些项目提出了这些定义。
我完全同意你的看法。 除非你用一点点盐来解释它们，否则给定的描述并没有多大意义。 对我来说，版本号的最后一个应该是构建 ，即每个编译更新的数字。 其他数字代表软件/ API的不同变化程度。
实际上，这就是版本号通常被使用的方式。 （当然，我是如何使用它们的。）
-
Major – 当软件的function集/ API发生显着变化时增加
-
次要 – 在进行显着更改，次要API更改或添加新function时增加
-
构建 – 在进行细微更改时增加，通常是错误修复和改进（尽管没有API更改）
-
Revision – 表示构建实例的唯一ID /编号