项目软件版本号管理规范.docx

项目软件版本号管理规范.docx

《项目软件版本号管理规范.docx》由会员分享，可在线阅读，更多相关《项目软件版本号管理规范.docx（7页珍藏版）》请在冰豆网上搜索。

项目软件版本号管理规范

项目软件版本号管理规范

编制

日期

2016.9.5

审核

日期

批准

日期

内部资料，注意保密

历史修改记录

版本号

修订内容

修订时间

修订人

V1.0

创建文档

2016.9.5

1.目的

1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到任何版本。

1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一管理。

1.3本文档是为规范研发部软件版本管理而制定的。

2.范围

2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：

2.2版本标识方法及管理

2.3版本升级

2.4文档及源码的备份制度 

2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使用按照文档及源码存放备份制度。

3.版本管理

3.1版本号规则

3.1.1每个归档版本都有两个版本号：

内部版本号和外部版本号。

版本号使用VP规则，V（Version）是指外部版本号（研发测试版本），P（Patch）是指补丁版本号（可选）。

3.1.2版本号命名：

V/B+主版本号+次版本号+修订版本号+日期版本号

3.2版本号修改规则

3.2.1主版本号：

当功能模块有较大的变动，比如增加模块或是整体架构发生变化。

此版本号由项目决定是否修改。

3.2.2次版本号：

相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。

此版本号由项目决定是否修改。

3.2.3修订版本号：

一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。

此版本号由项目经理决定是否修改。

3.2.4日期版本号：

用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。

此版本号由开发人员决定是否修改。

如：

V8.1.0.XXX（上一级版本号有变动时，下级要归零）

3.3版本号修改举例说明

如此时版本号为：

V8.1.0.XXX ，此时为内部测试阶段

3.3.1开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为：

V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为：

V8.1.1.XXX。

3.3.2如果对软件进行了一些功能上的改进或增强，进行了一些局部变动的时候要修改次版本号，如：

V8.2.0.XXXX（上一级有变动时，下级要归零）。

3.3.3当功能模块有较大变动，增加模块或整体架构发生变化时要修改主版本号，如新增加了退款功能，则版本号要改为：

V9.0.0.XXXX；

3.4版本控制记录

3.4.1版本状态变迁要遵守一定的规则，内部先生成一个内部版本，提交测试审批，生成外部版本。

（测试人员在测试过程中根据《软件测试规程》检测生成《软件测试报告》再由项目组内部讨论是否能生成新的版本）不通过则为无效版本，需要软件开发人员再进行修改，直至通过。

通过后生成表格记录，再和源码一起打包受控形成外部版本。

3.4.2版本审核记录表如下：

每次审核记录添加，审核通过后作为开发文档一起打包受控。

内部版本状态

外部版本状态

开发人

审核人

批准人

发布时间

V8.1.1.XXX

V8.1.1.XXXX

研发部软件工程师

3.5版本更新记录

3.5.1版本更新软件工程师根据项目内容的变更，优化软件功能的，需要变更内部版本号提交测试审批，通过了则由开发人员进行版本归档，（测试人员在测试过程中根据项目软件变更优化的内容，结合项目软件整体结合进行测试。

测试完成根据《测试报告》由项目组内部讨论是否能生成新的版本。

不通过则为无效版本，由开发人员再进行优化工作。

更新记录过程中生成表格记录，审核通过后和源码一起打包受控形成外部版本。

内部版本

外部版本

优化内容

优化记录

记录人

优化日期

V8.1.2.XXX

V8.1.2.XXX

功能

实现功能目的性

3.6版本受控说明：

3.6.1开发人员完成所负责模块的代码编写任务后，提交到项目经理处； 

3.6.2项目经理向测试人员提交测试任务； 

3.6.3测试人员准备测试所需的环境； 

3.6.4测试人员开展测试并根据《软件测试报告》实时提交BUG； 

3.6.5开发人员处理测试过程中所出现的BUG，并提交给测试人员进行回归测试，直至BUG被解决；

3.6.6测试基本完成后，测试人员提交测试报告；

3.6.7根据项目市场需求结合实际情况决定是否发布新的版本；

3.6.8测试人员与各相关人员经讨论后确定好新版本各项信息； 

3.6.9测试人员发布新版本；

4.版本升级

4.1版本升级原则

4.1.1版本升级应严格纳入版本管理的控制之下。

应当谨慎地控制版本的升级，保障高版本下的兼容性，提供严格定义的升级方法。

4.1.2记录版本升级过程。

每次版本升级，都要填写版本升级记录表，记录表样例如下：

（仅供外部版本升级）内部版本和修订版本分别使用版本审核记录表、版本更新记录表。

主版本

原版本

主版本发布时间

功能变更描述

发布责任人

批准人

备注

4.2新版本的发布

4.2.1新版本的发布指对外新版本程序的升级，内部版本程序和变更版本程序只对研发部内部升级。

流程如下：

1）根据项目进展情况，或者根据用户需要、市场需求进行发布准备。

2）将发布所需文件进行打包整理，放在指定目录中，给目录加上标签，标签中包含将要发布的版本信息。

3）同样对源码文件也要加上与版本信息相关的标签。

5.文档及源码存放备份制度

5.1开发文档

5.1.1各项目的开发文档根据对外新版本程序的发布做出相对应的变更，内部版本程序和更新的程序不做变更。

5.1.2根据各项目组自己的情况，将市场需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入备份文件中与源代码一起打包保存。

5.2版本归入版本库 

5.2.1测试和审批通过之后，由CMO（配置管理员）归入版本库，除了源文件，同时归档的有测试报告、版本配套表、升级指导书等相关文档。

5.2.2需有内部版本FTP空间，仅内部使用；

开发：

有上传/下载权限，无修改和删除选项；

测试：

只有下载权限；

技术：

只有下载权限；

运维/项目专员：

内部版本，复制到外部版本；

同意发布后：

技术从外部版本文件夹获取版本，给客户更新；

技术：

只有下载权限；

感谢下载!

欢迎您的下载，资料仅供参考