终于，结束了封闭式开发。我们的任务都减轻了不少。随着项目慢慢从偏技术转移到编业务。大多都是新的功能点开发。由于功能的需求是变化十分剧烈，时常有重要人物。如老板或重要客户来参观产品。每次在产品经理演示的时候，都会提出一些需求，而这些需求的优先级都比较高。

同时，我们还有需有一个正式发布的版本对公众进行服务。加上有每日的开发版本发布。需要我们对不同版本进行维护。

版本号规则，参考谷歌的版本管理方式：

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或新的需求变更。如果没有加班修改，过了一天再改，也会让显得有些陌生或者还需要一定时间才能转入指定的开发状态，会减低开发效率。