终于,结束了封闭式开发。我们的任务都减轻了不少。随着项目慢慢从偏技术转移到编业务。大多都是新的功能点开发。由于功能的需求是变化十分剧烈,时常有重要人物。如老板或重要客户来参观产品。每次在产品经理演示的时候,都会提出一些需求,而这些需求的优先级都比较高。
同时,我们还有需有一个正式发布的版本对公众进行服务。加上有每日的开发版本发布。需要我们对不同版本进行维护。
版本号规则,参考谷歌的版本管理方式:
1. 主版本号 当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。以十六进制BCD码表示:0、…、9。
2. 次版本号 当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。以及Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。以十六进制BCD码表示:0、…、9。
3. 编译次数 表示编译发布的次数,每次发布都会递增,以十进制数表示:492 表示第492次的编译和发布.
4. 后缀 属于可选部分。可以以四位的日期表示,如0420(4月20日);或者以Alpha、Beta、Release等来表示。或者像chromo一样使用签入次数。
例如:一次发布的版本号为:0.2.5.6_alpha
说明如下:
0:项目启动到样品阶段
2:大错没有,只有小bug
5:第五次拼接
0:未打补丁
Alpha表示是开发测试版本。
小结:
发布时间。初步定于天下午三点进行发布,需提前十五分钟向各位开发人员进行通知。在可能的时间内签入。其实,真正的发布时间一般都是在三点十分左右。一开始的时候大家都会拖一些时间发布,但是随着每天发布的习惯性,大家也不会想一口气把所有的任务都签入到源码管理中,只要能初步完成一些任务点就行了。
在三点发布还有另一个原因:如果产品经理或测试人员发现了功能点不正确,或者没有实现到位,可以在到下班的时间内去检查系统,并且发布到任务管理或者bug管理上。开发人员也可以有时间改动,毕竟刚才签入的代码。如果到下班才发布系统,则会让开发人员加班处理bug或新的需求变更。如果没有加班修改,过了一天再改,也会让显得有些陌生或者还需要一定时间才能转入指定的开发状态,会减低开发效率。