技术部软件版本规范
文档建立/修改记录：
版本管理规范
【新建项目版本管理部分】
1，项目组接到项目需求，
1.1，开发组出项目设计和开发计划；
1.2，测试在Git中建立空项目(项目名称开会时候会有，没有需要问)，形成master版本，版本设定为V0.0.0。

2，组长发邮件给技术总监，并且抄送给项目经理和测试。

邮件内容：开发计划文档url和开发版本号(V0.1.0)，请批准第一阶段(开发计划中会包含)开发。

3，得到批准开发回复后，测试从master(V0.0.0)建立分支版本(V0.1.0)，打开版本参与人员的更新权限，并且将url给组长。

4，组长download项目，上传项目可运行框架，并且更新GIT中的readme文档并通知开发；5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中，并且push前必须测试，保证代码不能有运行异常，导致无法测试
5.1，Push结束后，开发者继续开发下一个功能点。

5.2，push结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，测试人员需先关闭版本参与人员的更新权限，再按功能点来测试bug，然后更新bug文档和测试用例文档的内容(有无bug都需要更新)，随即打开更新权限并通知组长。

6，开发者下一个功能点提交时，同上要求。

7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长，继续进行测试最后一个功能点bug。

8，组长通知组员进行bug（bug一般会比较少，bug很多只能说明开发者开发质量有问题）修改，给出修改版本地址。

9，修改完毕后提交，测试人员再次关权限且测试，如仍然有bug存在，更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2)，随即给出版本url给组长。

ps：提交版本如有冲突找组长调节。

10，第一阶段开发完全完成后开始开发第二阶段任务，重复2~9步骤，相应的版本号会变为从V0.2.0开始，同里修改版本号则是V0.2.1/V0.2.2/V0.2.3......
11，当全部阶段任务完成(指的是开发完成并测试无bug)，测试将最新的修改完成的版本(应该是V0.x.x，x为任意数字)合并到master版本中，此时版本号设定为V1.0.0。

测试发邮件给
技术总监，抄送给项目经理、开发组长和运维人员，请批准线上发布，得到肯定回复后，运维开始执行发布。

邮件内容：项目软件上线文档url（存在石墨系统中），请批准线上发布。

【master版本修改版本管理部分】
12，承接上文，发布到线上的软件不排除有时会出现bug，此时如必须要解决这些bug，则重复上文的步骤1~步骤11，不同的地方在以下几点：
12.1，和上文1.2不同，测试人员任务不是在此处新建空项目，而是将master版本开分支(V1.0.1),然后给出url给组长；
12.2，此次修改的所有版本号则变为V1.0.x形式；
12.3，修改完成后（指的是bug俱已修复完成），测试再次封测，将分支权限关闭并且整合到V1.0.0版本的master中，继续按步骤上线等操作。

修复完成。

12.4，上线之后，又发现了bug，仍然需要修复，则再次重复12.1~12.3步骤，不过版本号变为V1.0.2/V1.0.3~~形式。

【项目整改版本管理部分】
13，日后，此项目需要整改(比如：增减模块、改变功能等)时，基本按照上面的1~12步骤执行，不同的地方在以下几点：
13.1，和上文1.2不同，测试人员任务不是在此处新建空项目，而是将master版本开分支，指定版本号为V2.0.0(master版本整改超过50%)或者V1.1.0(master版本整改小功能等),然后给出url给组长；
13.2，此次再开发任务的所有版本号则变为V2.x.x或者V1.1.x形式；
13.3，开发完成后（指的是再开发完成并测试无bug），测试封测，将分支权限关闭并且整合到现有的master版本中(V1.x.x)，继续按步骤上线等操作。

再开发完成。

版本管理规范流程图。