标签归档:software engineering

软件版本命名规范

version-control

       为了让软件管理简单、规范,软件开发过程中常常需要给软件一个版本号,但应该遵循怎样的规范呢? 为此,我们简单来说明版本号规范。,我们以版本号1.2.3.6789M1来做说明,各个位置的含义如下:

version

主版本号

主版本号一般用来表示应用的核心功能、代码的架构序列。一般在架构或者核心功能没有稳定时,主版本号会取0来表示。大家常常会看到国外有很多开源软件版本号是0.1.2这样的,说明它的架构还没有稳定下来。说句题外话,国内作者喜欢一上来就将主版本号设置为1,命名为1.0.1这样的。这个其实不够严谨。当该版本的架构或核心功能稳定后,我们就可以将主版本号命名为1.表示架构或者核心功能稳定了。比如我们1.2.3.6789M1这里1表示架构稳定了。

子版本号

子版本号一般表示应用的子功能变更序列。当子功能第一版发布时,一般会取1作为子版本号,表示第一版发布,如,0.1表示架构核心功能没有稳定,第一版子功能发布。而,如果主版本号为大于等于1的版本号时,第一版子功能发布时又会直接取0作为第一版的版本号,如1.0表示第一版发布。比如我们1.2.3.6789M1这里2表示是子功能的第二次发布,有子功能变化。

Fix版本号

这个fix版本号就是为了表示我们本次发布是fix bug版本。比如,我们要修复一个版本1.0的bug,第一次修复后要进行发布,这时应该将发布的版本号设置为 1.0.1, 表示该版本是1.0的第一次bug修复版本。第二次修复后,fix版本号递增,这样我们就能知道是第几次bug修复了。比如我们1.2.3.6789M1这里3表示是在1.2版本的第3次bug修复。

代码revsion id

这个表示我们代码是版本控制系统上的哪一个revision, 每次发布都应该带上当前代码的revision。这样便于我们看到版本就能定位到我们的源代码,方便问题调查。比如,1.0.1.6666, 这个版本号,我们就能定位,我们应该看源码控制系统的revision为 6666的代码。比如我们1.2.3.6789M1这里6789表示代码的revision是6789

Optional-flag

这个没有固定格式。一般是一个单词或者缩写。说明性文字。比如, 1.1.0.1111M1, 可能就表示这个是1.1.0的第一次历程碑版本, 1.1.0.1111beta就表示是1.1.0的beta版本。比如我们1.2.3.6789M1这里M1表示是1.2.3的第1次里程碑版。

以上就是版本号的基本规范。大家如果按照这个命名,基本上通过版本号就可以让他人了解你的功能及其变化情况。

0.7check规则

今天在工作中遇到个问题,发现有个已经单体测试完成的source严重与详细设计书不一致,经过调查发现,程序在单体测试开始过程中进行了不断的修正,而没有同步的将详细设计对应的进行修正。于是,我查看了版本发现,程序从单体测试开始到测试完成共修正了18次,而详细设计仅修改了7次,详细设计对应频率为7/18=0.39,这个比值直观的感觉就比较小了!然后我查看了没有不一致的代码和详细设计,并计算了这个比值,发现,它们基本在0.7左右波动。呵呵,也许这就是个规则,也就是说,平均每修改10次source就应该对应修改7次详细设计,小于这个值就很有可能出现不一致现象,一定要进行严格 check,而大于这个可能会导致大家的厌烦,所以我喜欢把这个称为0.7check规则。以后检查时先看这个频率

p=详细设计对应修改次数/source修改次数
当p<0.7时, 一定要进行再次check; 0.7=<p<0.8时,应该基本正常;p>=0.8时,详细设计修改次数过多,增加了工作量.
希望这个规则能对大家管理项目有所帮助.:)

作者:豆博草堂