新建的工程修改后多次生成,但版本号还是1.0.0.0。无奈又找出插件源码,加日志打印。结果证实事件触发正常。但代码中用于替换当前版本号的新版号居然与旧版本完全相同,都是1.0.0.0,当然跟没变一样了。由于这一段代码牵涉多个类和正则表达式之类,十分头疼。晚上回家,决心好好配置一下vs addin的调试,找出原因。但新建测试工程时,注意到了版本号风格versioning style还是默认值None-None-None-None,点击进去,竟然每个参数都有多种方案可选。既然有许多类型可选,那么None,很可能就是不变了。尝试将最后一个revsion号改为increment风格,再生成项目,OK,终于版本号变了。
下面列出几种主要的版本号风格及说明:
GNU 风格
主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]示例 : 1.2.1, 2.0, 5.0.0 build-13124管理策略:项目初版本时,版本号可以为 0.1 或 0.1.0,也可以为 1.0 或 1.0.0,如果你为人很低调,我想你会选择那个主版本号为 0 的方式;当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1;当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0,因而可以被忽略掉;当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1;编译版本号一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制。
Win风格
主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]示例: 1.21, 2.0管理策略:项目初版时,版本号为 1.0 或 1.00;当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1;当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0,因而可以被忽略掉;当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1;编译版本号一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制。另外,还可以在版本号后面加入 Alpha、Beta、Gamma、Current、RC (Release Candidate)、Release、Stable 等后缀,在这些后缀后面还可以加入1 数字的版本号。对于用户来说,如果某个软件的主版本号进行了升级,用户还想继续那个软件,则发行软件的公司一般要对用户收取升级费用;而如果子版本号或修正版本号发生了升级,一般来说是免费的。
Net F风格
主版本号.子版本号[.编译版本号[.修正版本号]]Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]版本号由二至四个部分组成:主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的;内部版本号和修订号是可选的,但是如果定义了修订号部分,则内部版本号就是必选的。所有定义的部分都必须是大于或等于 0 的整数。 应根据下面的约定使用这些部分:Major :具有相同名称但不同主版本号的程序集不可互换。例如,这适用于对产品的大量重写,这些重写使得无法实现向后兼容性。Minor :如果两个程序集的名称和主版本号相同,而次版本号不同,这指示显著增强,但照顾到了向后兼容性。例如,这适用于产品的修正版或完全向后兼容的新版本。Build :内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision :名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。
原创文章,作者:苏葳,如需转载,请注明出处:https://www.swmemo.com/591.html