软件项目版本管理规范总结

1.目的

       本文主要针对本人最近项目过程中多分支并行开发，代码合并后可能出现最新代码遗失、被覆盖和版本管理不完善等问题，结合优秀开源项目(主要是Cassandra)版本管理经验，优化项目的版本管理方法，为自己以后的软件项目提供版本规范和指导。

2.说明

        根据我们现有项目的经验，项目第1版都在trunk下开发，此时几乎不需要版本管理。等第1版测试通过上线后，由于运维期间的bug、新需求和新增业务等原因，会存在多个分支并行开发且需要合并到一起的情况，为了不使最新代码遗失、被覆盖，此时版本管理就显得特别重要了。而本文档主要为这期间的版本管理提供指导。

3.前提

        所有项目的版本号命名格式均采用GNU风格，即：主版本号.子版本号.修正版本号-编译版本号，如1.2.1- build13124。我们主要使用“主版本号.子版本号.修正版本号”格式，即1.2.1。

4.规范

1.       项目初版本时，主版本号从1开始，以后遇到重大变更依次累加。

2.       子版本号采用当月月份号，依次累加(如果今天是20130912，项目

建立时的版本号为1.9.0，到20140112，则版本号为1.13.0)。如果主版本号改变，子版本号采用当月月份号(如果今天是20140112，当前项目版本号为1.13.1，现在主版本号要改变，那新的版本号为2.1.0)。子版本号每月改变一次。

3.       修订版本号按当天是这月的第几周而定(如果今天是20130912，是这个月的第2周，那版本号为1.9.2)。修订版本号每周改变一次。

4.       每一次版本变化，不论局部修改或 bug修正，都必须记录在changes.txt里，并尽量与redmine关联。记录格式如下：

 

 

5.示例

 

        根据现有项目，项目版本的增长大致分为3种情况，即单向增长，多分支并行后合并和分支独立。下面以2.3节版本管理规范分别说明。

    图例说明：横轴为时间，每格为一周。纵轴每一块代表模块，组成一个项目。数字为版本号。

 

5.1单向增长

 

       单向增长即每个模块没有分支，只有子版本号和修正版本增长。每个时期每个模块的修正版本号可能不一样，但是部署的版本一致。部署版本号为所有模块的最大版本号(例如在2013年8月份第3周，此时模块1的版本为1.8.3，模块2的版本为1.8.2，模块3的版本为1.8.1，则所有模块的部署版本号为1.8.3)。

       依据上图，在2013年9月份第4周，各个模块的changes.txt包含如下内容。

       模块1：

 

       模块2：

 

        模块3：

 

5.2多分支并行后合并

 

        项目上线后，由于新需求的增加需要改动部分模块的主版本号。如在2013年8月第3周模块2新建了2.8.3版本，周期为4周，到2013年9月第1周结束。在这期间模块1和模块2出现一些bug需要立即解决，这时模块2的1.8.4版本，模块1的1.8.4版本和模块2的2.8.3版本并行开发，在模块2的2.8.3版本完成之前，模块1和模块2以1.8.4部署。

        模块2的2.8.3上线之前，需要将1.8.4版本的变化合并到2.8.3版本中。上线后1.8.4版本不再开发，以后的新需求和bug修改在2.8.3版本基础上修改。而其它模块在模块2的2.8.3版本上线之后的修改需要统一版本，以2.8.3版本为基础增长(如2013年9月第2周模块1的bug修改，版本从1.8.4直接到2.9.2)。

     依据上图，在2013年9月份第4周，各个模块的changes.txt包含如下内容。

     模块1

 

         模块2：

 

5.3分支独立

 

        分支独立跟单向增长差不多，唯一的差别是1个模块有多个正在使用的分支。如上图模块2在2013年8月第3周新建了分支2.8.3版本，以后该分支相当于一个模块维护其版本号，没有受该分支影响的其他模块还在原来的主版本上维护版本号，如模块1后续的bug修改都是在主版本1上增加版本号。

         依据上图，在2013年9月份第4周，各个模块的changes.txt包含如下内容。

         模块1：

 

           模块2V1版本：

 

            模块2V2版本：

 

6.本规范优点

1.       添加changes.txt记录每个版本的修改，如有代码合并可以降低出错的几率，并且可以关联redmine。

2.      项目版本号规则简单、普及容易、一目了然，并且可以追溯修改时间。