软件版本管理标准规范.doc

XXXX企业技术文件软件版本管理规范XXXX企业二一八 年 一 月目 录第1章 引言- 1 -1.1 目标- 1 -1.2 适用范围- 1 -1.3 术语定义和缩写词- 1 -1.4 统一大小写- 1 -1.5 参考资料- 1 -第2章 版本规范- 2 -2.1 版本格式- 2 -2.2 版本升级规则- 2 -第3章 TAG 规范- 3 -3.1 TAG 转换规则- 3 -3.2 版本 TAG- 3 -3.2.1 ALPHA测试 TAG- 3 -3.2.2 BETA测试 TAG- 3 -3.2.3 Release TAG- 3 -3.2.4 产品基线 TAG- 4 -第4章 BRANCH 规范- 5 -4.1 固定后缀- 5 -4.2 BRANCH 转换规则- 5 -4.3 项目 BRANCH- 5 -第1章 引言1.1 目标经过该文档来统一、规范企业全部软件产品版本管理，使得版本管理愈加正式和有效。本文档自1月1日开始实施。1.2 适用范围本规范中要求相关内容适应于企业全部软件产品版本管理。1.3 术语定义和缩写词版本号：产品/模块版本标识TAG：SVN 中标识版本集合工具和术语BRANCH：即分支，SVN 中支持并行开发工具和术语1.4 统一大小写版本管理中全部固定字串统一为大写版本管理中全部提到产品/模块名称统一为小写1.5 参考资料CMMI 规范之-SCM软件版本管理规范第2章 版本规范2.1 版本格式版本号包含：产品/模块简称、主版本号、副版本号、子版本号、build 号格式： . .2.2 版本升级规则 主版本号升级规则 新产品或模块立项，主版本号为0； 主体构件进行重大修改，主版本号加1； 主版本号变更时，副版本号同时置 0。 副版本号升级（关键针对新功效） 新产品或模块，副版本号为 1； 主体构件重大修改，副版本号加 1； 主体构件之间接口协议重大修改，副版本号加 1； 和其它产品或模块之间接口协议重大修改，副版本号加 1； 重大功效增加或增强，副版本号加 1； 当副版本号变更时，子版本号同时置 0。 子版本号升级（关键针对修改bug） 新产品或模块立项，子版本号为 0； 为增强现有功效模块，不增加新功效模块，主体构件未做重大修改，而且主体构件之间接口协议也未做重大修改，子版本号加1； 为修改 bug，而产品主体构件未做重大修改，而且产品主体构件之间接口协议也未做重大修改，子版本号加1。 build 号升级 build 号部分为生成版本日期； 每次送测必需有 build 号，上线等也必需有build 号； 例：050331第3章 TAG 规范3.1 TAG 转换规则从版本号和项目编号转换成 TAG 对应部分遵照以下标准：a、字母和数字不变b、空格“ ”转换成下划线“_”c、小数点“.”转换成减号“-”3.2 版本 TAG3.2.1 ALPHA测试 TAGAlpha版：内测版。专业测试人员测试用，通常而言，该版本软件Bug较多，需要继续修改。格式：_-_ ALPHA格式（例）：dhtx_0-1-0-150331_ALPHA3.2.2 BETA测试 TAGBeta版：公测版。该版本相对于Alpha版已经有了很大改善，消除了严重错误，但还是存在着部分缺点，需要经过数次测试来深入消除，此版本关键对像是产品用户。格式：_-_ BETA格式（例）：dhtx_1-1-21-150331_BETA3.2.3 Release TAGRelease版：该版本意味“最终版本”，在前面版本一系列测试版以后，终究会有一个正式版本，是最终交付用户使用一个版本。该版本有时也称为标准版。通常情况下，Release不会以单词形式出现在软件封面上，取而代之是符号(R)格式：_-_ R格式（例）：dhtx_1-1-21-150331_R3.2.4 产品基线 TAG定义产品基线 后缀是：_PD_BL格式：_-_PD_BL格式（例）：dhtx_1-1-21-050331_PD_BL第4章 BRANCH 规范4.1 固定后缀BRANCH名称固定后缀为：_BRANCH4.2 BRANCH 转换规则BRANCH转换规则同TAG 转换规则4.3 项目 BRANCH项目分支用来支持并行项目标开发工作，同一项目使用相同项目分支格式：_BRANCH第5章 代码存放及公布规范5.1 代码存放规则1. 软件开发在svn对应项目标trunk目录中进行。2. 需要公布测试版本在svn对应项目标tag目录中进行标识，命名规则参见第三章。5.2 公布规则1. 软件公布由项目经理进行操作。2. 项目经理在tag目录中对待测试版本进行标识。注意，不要修改tag目录中代码。3. 用标识版本打包生成测试包，上传到测试FTP服务器。