项目软件版本号管理规范

项目软件版本号管理规范项目软件版本号管理规范 编制日期 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.13.1 版本号规则版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP 规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁 版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号 . ;. 3.23.2 版本号修改规则版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变 动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的 协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目 决定是否修改。 3.2.3修订版本号：一般是 Bug 的修复或是一些小的变动或是一些功能的扩 充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。此版本 号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.33.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.43.4 版本控制记录版本控制记录 3.4.1 版本状态变迁要遵守一定的规则，内部先生成一个内部版本，提交测试 审批，生成外部版本。（测试人员在测试过程中根据软件测试规程检测生 成软件测试报告再由项目组内部讨论是否能生成新的版本）不通过则为无 效版本，需要软件开发人员再进行修改，直至通过。通过后生成表格记录，再 和源码一起打包受控形成外部版本。 3.4.2 版本审核记录表如下：每次审核记录添加，审核通过后作为开发文档一 起打包受控。 内部版本状 态 外部版本状 态 开发人审核人批准人发布时间 V8.1.1.XXXV8.1.1.XXX X 研发部软件 工程师 3.53.5 版本更新记录版本更新记录 3.5.1 版本更新软件工程师根据项目内容的变更，优化软件功能的，需要变更 内部版本号提交测试审批，通过了则由开发人员进行版本归档，（测试人员在 测试过程中根据项目软件变更优化的内容，结合项目软件整体结合进行测试。 测试完成根据测试报告由项目组内部讨论是否能生成新的版本。不通过则 为无效版本，由开发人员再进行优化工作。更新记录过程中生成表格记录，审 核通过后和源码一起打包受控形成外部版本。 内部版本外部版本优化内容优化记录记录人优化日期 . ;. V8.1.2.XXXV8.1.2.XXX 功能实现功能目 的性 3.63.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.14.1 版本升级原则版本升级原则 4.1.1版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级， 保障高版本下的兼容性，提供严格定义的升级方法。 4.1.2记录版本升级过程。每次版本升级，都要填写版本升级记录表，记录表 样例如下：（仅供外部版本升级）内部版本和修订版本分别使用版本审核 记录表、版本更新记录表。 主版本原版本主版本发 布时间 功能变更 描述 发布责任 人 批准人备注 . ;. 4.24.2 新版本的发布新版本的发布 4.2.1新版本的发布指对外新版本程序的升级，内部版本程序和变更版本程序 只对研发部内部升级。流程如下： 1) 根据项目进展情况，或者根据用户需要、市场需求进行发布准备。 2) 将发布所需文件进行打包整理，放在指定目录中，给目录加上标签，标 签中包含将要发布的版本信息。 3) 同样对源码文件也要加上与版本信息相关的标签。 5. 文档及源码存放备份制度 5.15.1 开发文档开发文档 5.1.1各项目的开发文档根据对外新版本程序的发布做出相对应的变更，内部 版本程序和更新的程序不做变更。 5.1.2根据各项目组自己的情况，将市场需求记录、总体设计文档、详细设计 及数据结构文件、测试记录、用户手册等放入备份文件中与源代码一起打 包保存。 5.25.2 版本归入版本库版本归入版本库 5.2.1 测试和审批通过之后，由 CMO（配置管理员）归入版本库，除了源文件， 同时归档的有测试报告、版本配套表、升级指导书