任何一个产品都有版本,而作为SDK来说,版本会更加重要。游戏会根据你的版本来选择接入的功能,我们定位问题也需要追踪回朔版本号,进而定位代码SVN版本。而区分这些版本的方法就是版本号。
目前我们的版本只有字符版本,没有数字版本。当有比对版本的需要的时候,我们会把字符版本转化为数字版本号。例如把2.0.0a转化为200,然后用这个数字对比。其实这样是有问题的,1.3系列我们出到了1.3.11a。将来如果有13.1.1a。两个的数字版本号就是1311,会有问题。但是如果我们版本都13.1.1a,还有人用1.3.11a。其实他的版本早就应该更新了。
对于具体的版本,为了方便定位问题,除了对外的版本号,我们还有对内的基线号,或者tag标签。Tag标签(基线号)主要是用来精确定位版本对应的svn记录。我们的tag(基线号)是由Tag_版本号.持续集成build号_SVN版本号组成。例如:Tag_2.7.2.246_55349
,我们在持续集成时会按照这个值生成一份svn的tag。定位问题的时候,直接按照tag回朔即可。
这里其实我目前也没有想到比较好的解决办法。建议版本号参考Android标准,有两个,一个数字版本号,用于SDK内部,方便比对版本的时候使用。一个是字符版本号,也就是版本名,用于标识版本,提供给外部应用调用或者产品维度的区分。
目前的主流版本号都是分三段:主版本、特性版本、修正版本。例如:2.0.1这种。主版本号主要用于大版本的发布,特性版本主要用于更新迭代,修正版本号主要用于bug修复。
关于数字版本号,可以自己来直接维护,也可以通过一定的规则来生成。如果是自己维护,像SDK存在多个分支同时维护的情况下,维护起来就会很复杂,问题很多。这里给两个个人觉得可行的方法吧。
最完美的方案还是直接使用git的提交次数,或者buildNo 作为版本号,这样可以完美做到版本号全局唯一
如果数字版本号一定要由字符版本号生成,同时建议字符版本号中的修正版本号用两位位来围护,例如2.0.00;或者2.0.01这种。对应的转化出的数字版本号为20000和20001。,或者在版本比较的时候逐级转化为浮点数去比对
这里还是直接写经验吧:
首先:
自动构建打一个。我们在自动构建时,会通过构建脚本生成一个版本配置相关的文件,在这个文件里面,我们会打上一些对于我们后续定位问题有需要的内容。其中就包括版本号。具体的配置文件事例如下:
VERSION=1.3.1
SVN_REVISION=55384
BASE_LINE=Tag_AGSDK_1.3.1.304_55384
DATETIME=2015-04-29 12:23:56.279