Documentation说完整版本号包含四个部分：
主要。次要。构建。修订，其中
内部版本：内部版本号不同表示重新编译了相同的源。处理器，平台或编译器更改时，可能会使用不同的内部版本号。
修订版：具有相同名称，主要和次要版本号但具有不同修订版的程序集可以完全互换。可以使用更高的修订版号来修复先前发布的程序集中的安全漏洞。
因此，看来修订与{strong> PATCH 版本在Semantic Versioning 2.0.0方面相对应，并且 build 被映射到{{ 3}}。因此，版本1.2。x。4会晚于版本1.2。y。3，因为它们具有相同的主要和次要数字，但版本号为1.2 。x。4 修复了先前发布的程序集中的安全漏洞。
但是对于ClickOnce部署，此声明不正确。以下步骤将成功完成：
- 使用Visual Studio创建一个空的Windows窗体应用程序。
- 转到项目属性中的发布标签，然后指定发布文件夹位置。
- 将版本号设置为
1.2.3.4。 - 点击立即发布按钮。
- 将版本更改为
1.2.4.3。 - 点击立即发布按钮。
但是，如果您交换步骤3和5，则会重现以下警告：
已发布的版本1.2.4.3将替换为较早的版本（1.2.3.4）。
因此，如果版本号的内部版本值不同，则修订版值将被忽略。而且，它断言1.2.4.3的版本比1.2.3.4的更新。
Version.CompareTo方法的文档证实了这种行为：
Version的重要性降序是：主要，次要，内部和修订。
但是，如果我重建旧的修补程序，提交主要和次要等于最新版本的相同部分，那会是什么？ CI / CD构建计数器的值将增加。因此，最新版本将比最新版本“旧”。
另一个示例是将模数用于CI / CD构建计数器，以抵消build metadata build 值。在UInt16.MaxValue-1之后，计数器将被“重置”为0。因此，如果未更改主要和次要，它将生成比以前“旧”的版本。
因此，我感到怀疑是否应该使用文档中指定的版本号格式。代替使用主要。次要。修订。构建会产生什么后果？是否可以要求microsoft进行文档审查？