为什么.NET中的System.Version定义为Major.Minor.Build.Revision？
为什么.NET中的System.Version定义为Major.Minor.Build.Revision？几乎每个人（包括我）似乎都同意修订属于第三位，而“构建”或任何你想称之为的东西属于最后。
微软是否以这种随意的方式使用这些数字，例如3.5.3858.2，或者名称本身只是倒序？例如，如果您要按照 Major.Minor.Build.Revision 的顺序编写自己的 Version 类，那么在转换为 System.Version 时交换最后两个组件是否合适，或者您是否忽略它并只是假装名称落后吗？
Why is System.Version in .NET defined as Major.Minor.Build.Revision? Almost everyone (including me) seems to agree that revision belongs in third place, and "build" or whatever you'd like to call it belongs last.
Does Microsoft even use the numbers in this haphazard way, e.g. 3.5.3858.2, or are the names themselves just backwards? For example if you were to write your own Version class with the order Major.Minor.Build.Revision, would it be proper to swap the last two components when converting to a System.Version, or do you ignore it and just pretend the names are backwards?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为困惑来自于大多数人认为的“修订”和微软所做的< /a>:
构建： 内部版本号的差异表示同一源代码的重新编译。由于处理器、平台或编译器的变化，这是适当的。
修订版：具有相同名称、主要版本号和次要版本号但不同修订版的程序集旨在完全可互换。这适用于修复先前发布的程序集中的安全漏洞。
安全修复角度对他们来说可能更常见，似乎是将其放在最后的一个不错的理由，因为“最微小的”变化。
I think the confusion comes what most consider a "revision" and what Microsoft does:
Build: A difference in build number represents a recompilation of the same source. This would be appropriate because of processor, platform, or compiler changes.
Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. This would be appropriate to fix a security hole in a previously released assembly.
The security fix angle, probably much more common for them, seems to be a decent reason to have it in last place, as the "most-minor" change.
我意识到我来参加聚会有点晚了，但我想分享我的两便士为什么构建和修订的顺序是“错误的”。与其说它们的顺序错误，不如说它们的顺序不任何。
归根结底，程序集的版本是Major.Minor。在上述链接中，微软表示，“程序集的后续版本仅在以下方面有所不同：内部版本或修订号被视为先前版本的修补程序更新。” [我的重点]
Build 代表同一源代码的重新编译。 修订版代表代码更改，但可以与同一[Major.Minor]版本的其他修订版完全互换。但两者都不优先于另一个。
因此，总而言之，不要将其视为：
而是：
I realize I'm coming to the party a bit late, but I wanted to share my twopence on why the order of build and revision are "wrong." It's not so much that they're in the wrong order, but that they're not in any order.
The version of an assembly, when it comes down to it, is Major.Minor. From the aforementioned link, Microsoft says, "Subsequent versions of an assembly that differ only by build or revision numbers are considered to be Hotfix updates of the prior version." [My emphasis]
The Build represents a recompilation of the same source. The Revision represents a code change, but one that is fully interchangable with other revisions of the same [Major.Minor] version. But neither takes precedence over the other.
So, in summary, don't think of it as:
But instead:
如果您让它默认，例如通过指定
[assemble: AssemblyVersion("1.1.*")]，然后第三个数字每天递增，第四个数字是自午夜以来的秒数除以二（以消除一天内是否有多个构建的歧义）。
微软似乎将“build”用作“day”的同义词：也许这与“daily builds”的想法有关；因此，“修订版”是（每日）构建的另一个版本。
If you let it default, e.g. by specifying
[assembly: AssemblyVersion("1.1.*")],then the third number increments each day, and the fourth number is the number of seconds since midnight, divided by two (to disambiguate if there's more than one builds in a single day).
Microsoft seem to be using "build" as a synonym of "day": perhaps that's related to the idea of "daily builds"; and a "revision" is then therefore another version of the (daily) build.
迟到的答案，但我觉得其他答案可以扩展一下。
术语“构建”和“修订”只是 Microsoft 术语。 System.Version 类不关心您如何分配它们。
至于切换各部分的顺序以匹配您自己的术语，我想说您基本上应该完全忽略这些单词，而是考虑 System.Version 真正 定义的内容：
它可以的字符串格式解析并生成：
这意味着，如果您习惯将自己的版本格式化为
xyzw，那么你应该这样实例化 Version 类：
任何其他参数顺序都不会与 Parse() 和 ToString() 匹配
会做的。如果交换 z 和 w，则 ToString() 将输出 xywz
这会让每个人感到困惑：
A 版本比较和排序顺序，对版本进行排序
首先由
主要，然后是次要，然后构建，然后修订，就像我们大多数人所做的那样
预计。即1.2.5晚于1.2.3.7。
因此，如果您将版本字符串样式设置为 1.2.6.4 并希望将其设置为
被认为比 1.2.5.8 更新，那么不要改变其中各部分的顺序
Version 构造函数。
简而言之，虽然主要/次要/构建/修订这些词可能会给出考虑到变化量应该增加哪个数字的线索，但术语对类的实际使用方式影响很小。格式化和排序才是重要的。
Late answer, but I feel the other answers could be expanded on a bit.
The terms "build" and "revision" is just Microsoft terminology. The System.Version class does not care in any way how you assign them.
As for switching the order of parts to match your own terminology i would say that you should basically ignore the words entirely and instead consider what the System.Version really defines:
A string format that it can parse and generate:
This means that if you are used to having you own version formatted as
x.y.z.w, then you should instantiate the Version class this way:
Any other parameter order will not match what Parse() and ToString()
would do. If you switch z and w, then ToString() would output x.y.w.z
which would be confusing for everyone if you expect x.y.z.w.
A version comparison and sort order, whereby versions are sorted
first by
major, then by minor, then build, then revision, as most of us would
expect. That is, 1.2.5 is later than 1.2.3.7.
So if you style your version string as 1.2.6.4 and want that to be
considered newer than 1.2.5.8, then do not switch the order of the parts in
the Version constructor.
In short - while the words major/minor/build/revision might give a clue as to which number should be increased considering the amount of changes, the terminology have very little impact on how the class is actually used. Formatting and sorting is what matters.