微软是否会以这种杂乱无章的方式使用数字,例如 3.5.3858.2,还是这些名称本身就是反过来的?例如,如果您要编写自己的 Version 类,并采用 Major.Minor.Build.Revision 的顺序,那么在转换为 System.Version 时交换最后两个组件是否正确,还是忽略它并假装名称是反过来的?
我认为混淆是因为大多数人认为“修订版本”和Microsoft的定义不同:
Build: 构建编号的差异表示相同源代码的重新编译。这可能是由于处理器、平台或编译器更改所导致的。
Revision: 具有相同名称、主要版本号和次要版本号但不同修订版本的程序集旨在完全互换。这对于修复先前发布的程序集中的安全漏洞是合适的。
安全修补方面,可能更常见,似乎是将其放在最后一个位置的一个不错的理由,作为“最小”的变化。
System.Version
是否合适?还是保持不变,并让它们在每个结构中被相反的名称调用? - Jake PetroulesMajor.Minor.Revision.ChangeSet
,这样我只需瞥一眼号码就可以得到源代码控制中正在运行的确切代码。由于我们进行持续集成,对于我们来说,变更集和构建编号是同义词,这是有意义的...但不确定在其他地方是否适用。 - Nick Craver+ Major
|
+-+ Minor
|
+-+ Build
|
+-+ Revision
+ Major
|
+-+ Minor
|
+-+ Build
|
+-+ Revision
微软是否会以3.5.3858.2这样的不规则数字格式来使用版本号?
如果你让它默认,例如通过指定[assembly: AssemblyVersion("1.1.*")]
,那么第三个数字将每天递增,第四个数字是从午夜开始的秒数除以二(以消除如果在一天内有多个构建的歧义)。
几乎所有人(包括我)似乎都认为修订号应该放在第三位,“build”或者其他你想称呼它的东西应该放在最后。
微软似乎将“build”作为“day”的同义词:也许这与“每日构建”的概念有关;而“revision”则是(每日)构建的另一个版本。
虽然晚了一些,但我觉得其他答案可以再详细阐述一下。
“构建”和“修订版”这些术语只是微软的用语。System.Version类不在乎你如何分配它们。
至于更改部件顺序以匹配您自己的术语,我认为您应该完全忽略这些单词,并考虑System.Version 真正定义的内容:
A string format that it can parse and generate:
major.minor[.build[.revision]]
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:
new Version(x, y, z, w)
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.
简而言之,虽然主要/次要/构建/修订这些词汇可能会提示应该增加哪个数字,但这些术语对类的实际使用几乎没有影响。格式和排序才是最重要的。
Major.Minor.Micro-Build
有什么问题? - Yousha Aleayoub