某软件有限公司文档版本管理规范
【管理制度】某软件有限公司文档版本管理规范(doc 15页)
【管理制度】某软件有限公司文档版本管理规范(doc 15页)部门： xxx时间： xxx整理范文，仅供参考，可下载自行编辑密级：内控研发本部版本管理规范V1.0浪潮集团山东通用软件有限公司目录文档类别使用对象 (2)1．引言 (3)1.1目的 (3)1.2范围 (3)1.3术语定义 (3)1.4参考资料 (4)1.5版序控制记录 (4)1.6版本更新记录 (4)2．版本管理 (5)2．1版本标识方法 (5)2．1．1正式版本 (5)2．1．2特殊版本 (5)2．2目录结构 (5)2．3文档的存放 (7)2.3.1 当前版本和历史版本的存放 (7)2.3.2 开发文档的存放 (7)2.3.3 源代码的存放 (7)2.3.4 SQL语句的存放 (7)2.3.5发行文档的存放 (8)2．4权限控制管理 (8)3．更新管理 (8)3．1源程序的修改 (8)3．2已发布版本的维护及修改 (9)3．3外出人员对产品的修改 (9)3．4版本升级 (12)3.4.1 版本升级原则 (12)3.4.2 新版本的发布 (12)3.4.3 安装盘制作步骤 (13)4．备份管理 (13)5．用户版本管理 (14)文档类别使用对象文档类别该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。
使用对象该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。
未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言1.1目的本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。
1.2范围本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括：●版本标识方法●软件系统数据的存放●文档的修改控制●文档的备份制度1.3术语定义SCMSoftwere Configuration Management缩写SVMSoftware Version Management缩写文档一种数据媒体和其上所记录的数据。
软件有限公司文档版本管理规范
软件有限公司文档版本管理规范12020年4月19日密级:内控研发本部版本管理规范V1.0浪潮集团山东通用软件有限公司目录文档类别使用对象 ............................ 错误!未定义书签。
1．引言..................................... 错误!未定义书签。
1.1目的................................... 错误!未定义书签。
1.2范围................................... 错误!未定义书签。
1.3术语定义............................... 错误!未定义书签。
1.4参考资料............................... 错误!未定义书签。
1.5版序控制记录........................... 错误!未定义书签。
1.6版本更新记录........................... 错误!未定义书签。
2．版本管理................................. 错误!未定义书签。
2．1版本标识方法.......................... 错误!未定义书签。
2．1．1正式版本.......................... 错误!未定义书签。
2．1．2特殊版本.......................... 错误!未定义书签。
2．2目录结构.............................. 错误!未定义书签。
2．3文档的存放............................ 错误!未定义书签。
2.3.1 当前版本和历史版本的存放........... 错误!未定义书签。
2.3.2 开发文档的存放..................... 错误!未定义书签。
2.3.3 源代码的存放....................... 错误!未定义书签。
公司内部软件版本管理规范-202009
软件版本管理规范版本变更记录目录1引言 (5)1.1目的 (5)1.2范围 (5)2原则 (5)3角色职责 (6)4版本管理 (6)4.1版本管理流程 (6)4.1.1部门职责及输出物 (6)4.1.2版本管理流程图 (7)4.1.3禅道项目管理流程图 (8)4.2版本标识方法 (8)4.2.1正式版本 (8)4.2.2内部测试版本 (9)4.3版本升级管理 (9)4.3.1版本升级原则 (9)4.3.2新版本发布原则 (10)4.4文档的存放 (11)4.4.1当前版本和历史版本的存放 (11)4.4.2开发文档的存放 (11)4.4.3源代码的存放 (11)4.4.4SQL语句的存放 (11)4.4.5发行文档的存放 (12)4.5权限控制管理 (12)5版本提交规则 (12)5.1开发交付测试要求 (12)5.2测试接收标准 (13)5.3测试中断标准（冒烟测试） (13)5.4测试通过标准 (13)6备份管理 (14)7各开发组提交文档及源码以及规则 (14)8版本发布流程 (15)1引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。
1.1目的本文档的编制是为了规范产品管理中心、运营开发中心、产品开发中心、项目管理中心对软件产品版本的管理。
1.2范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括：➢版本标识方法➢软件系统数据的存放➢文档的修改控制➢文档的备份制度2原则软件版本发布管理应遵循以下原则：1）实施版本变更应符合以下原则之一：✓为满足客户新业务、新功能需求；✓为满足提高业务质量、提升业务性能指标和容量扩充的需求；✓为解决软件故障和软件稳定性、安全性、可控性问题；✓为了提高软件可维护性。
软件版本管理规范
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 -I第1章引言1.1目的通过该文档来统一、规范公司的所有软件产品的版本管理，使得版本管理更加正式和有效。
软件版本管理规范
软件版本管理规范软件版本管理规范第一章目的本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。
1.第二章适用范围所有系统开发及实施项目的软件项目都应进行版本管理。
项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。
2.第三章职责配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。
此岗位可由开发或测试人员兼任。
3.第四章内容4.1. 版本管理对象包括但不限于：项目总体计划可行性研究报告开发计划需求说明书需求设计原型设计说明书系统开发变更申请单系统管理手册用户操作手册培训计划培训记录源程序支持系统运行的配置文件存储过程脚本测试计划测试用例测试脚本测试报告上线计划上线申请版本维护日志4.2. 配置库的目录结构每个项目在配置库中应拥有唯一的项目名称。
配置库目录结构与项目内部的目录结构建议按下列格式创建。
配置库目录结构规划：┠tags(发布)┃├v1.0.0_T1_2016909┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109┃├v1.1.0_T1_20170109┃└v1.1.0_R1_20170209┠trunk(主版本)┃└projectA┃├src┃├MY_MOOC┃├doc┃├tool┃├。
┖branches(分支)├SY_ABC├TJ_ABC├WH_MOOC其中，项目内部的目录结构：|–projectA|–src （保存该项目的源程序）|–doc （保存项目相关文档）|–000.项目管理（保存项目过程管理相关文档）|–010.项目计划（保存项目计划相关文档）|–020.项目需求（保存项目需求相关文档）|–030.系统设计（保存项目设计相关文档）|–030.系统测试（保存项目代码测试相关文档）|–040.系统实施（保存项目部署实施相关文档）|–050.系统运维（保存项目运维文档，包括培训、用户手册等）|–060.技术资料（保存项目技术文档，包括第三方技术资料等）|–。
软件产品研发版本管理规范
XXX有限公司软件产品研发版本管理规范2022年10月修订记录目录1、版本管理工具 (4)2、分支分类 (4)2.1 长期分支 (4)2.2 临时分支 (4)3 分支管理 (5)3.1 master分支 (5)3.2 develop分支 (5)3.3 feature（特性）分支 (6)3.3.1 feature分支开发步骤 (6)3.3.2 feature分支规范 (6)3.4 release（发布）分支 (7)3.4.1 release分支开发步骤 (7)3.4.2 release分支规范 (8)3.5 hotfix（Bug）分支 (8)3.5.1 hotfix分支开发步骤 (8)3.5.2 hotfix分支规范 (9)3.6 分支管理原则 (9)4 版本管理检验标准 (10)本规范适用于XXX有限公司自有产品研发过程的版本管理，包括程序源代码、文件、配置、测试程序、各种自动化脚本等，目的是用于规范产品研发过程中版本的管理，提高生产环境的可靠性、稳定性、弹性和安全性。
1、版本管理工具统一采用GitLab作为版本管理工具。
2、分支分类2.1 长期分支2.2 临时分支3 分支管理3.1 master分支1、生产环境Bug重现与调查生产环境发生问题时，通过master分支可以清楚地知道Bug发生的生产环境所对应的源代码基线，通过这条基线进行Bug重现。
2、新的功能发布以master分支为基础创建feature分支进行新功能开发，通过测试后，确认此分支功能可以发布，便可与master分支进行合并，合并后以master分支作为发布基线，发布时必须附加版本号，同时可将feature分支删除。
3、紧急Bug修复发布与master分支更新在生产环境出现Bug后，在master分支基础上创建hotfix分支进行Bug修复，修复紧急Bug之后，必须合并到master分支，合并后以master分支作为发布基线，同时可将hotfix分支删除。
软件版本管理规定(范本)
软件版本管理规定（范本）1范围本标准规定了软件版本的控制与管理。
本标准适用于软件版本的控制与管理。
2术语和定义下列定义适用于本标准。
2.1软件指与产品相关的所有软件，可以分为产品软件和演示软件。
2.2产品软件已签订合同，有明确交付日期的产品。
2.3演示软件处于研发阶段，并未正式投入生产的应用。
3软件版本命名规则3.1软件版本命名组成产品的正式软件版本命名由四部分组成。
第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。
产品的演示版本命名由四部分组成。
第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。
3.2产品软件版本命名产品软件版本的命名规则如下所示:产品标识ZS_VX.Y.Z_YYYYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
3.3演示软件版本命名演示软件版本的命名规则如下所示:产品标识YS_VX.Y.Z_YYYYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
3.4 正式版本号的升级规则软件的正式版本号升级，应该能体现出版本继承性关系，根据软件改动的大小，进行正式版本号升级。
3.4.1软件版本升级规则1)研发阶段主版本X的值为0，上线主版本X升级为1，后续根据系统调整需求大小或者合同的约定修改主版本号，如第一期合同主版本号为1，第二期合同主版本号为2；2)软件的初始正式版本号为V1.0.0；3)软件次版本号根据修改的功能及工作量依次递增。
如增加一项大的功能，则次版本号增加1；4)修订号及时间：在没有增加或减少大功能情况下的改动，使用修订号。
同一天发布的修订版本不超过10个，如2018年3月1日，共对一个软件做了3次修改，软件主版本号及次版本号为1和1，则这一天发布的版本分别为:ZS_V1.1.0_20180301、ZS_V1.1.1_20180301、ZS_V1.1.2_20180301。
3.4.2演示版本升级规则1）演示版本X的值为0，不做升级。
软件版本管理制度样本
软件版本管理规范系统软件开发部-9-20目录1引言 ................................................................................................................................. 错误!未定义书签。
1.1目............................................................................................................................. 错误!未定义书签。
1.2范畴......................................................................................................................... 错误!未定义书签。
1.3术语定义................................................................................................................. 错误!未定义书签。
1.4版序控制记录......................................................................................................... 错误!未定义书签。
1.5版本更新记录......................................................................................................... 错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
密级：内控研发本部版本管理规范V1.0浪潮集团山东通用软件有限公司目录文档类别使用对象 (2)1．引言 (3)1.1目的 (3)1.2范围 (3)1.3术语定义 (3)1.4参考资料 (4)1.5版序控制记录 (4)1.6版本更新记录 (4)2．版本管理 (5)2．1版本标识方法 (5)2．1．1正式版本 (5)2．1．2特殊版本 (5)2．2目录结构 (5)2．3文档的存放 (7)2.3.1 当前版本和历史版本的存放 (7)2.3.2 开发文档的存放 (7)2.3.3 源代码的存放 (7)2.3.4 SQL语句的存放 (7)2.3.5发行文档的存放 (8)2．4权限控制管理 (8)3．更新管理 (8)3．1源程序的修改 (8)3．2已发布版本的维护及修改 (9)3．3外出人员对产品的修改 (9)3．4版本升级 (12)3.4.1 版本升级原则 (12)3.4.2 新版本的发布 (12)3.4.3 安装盘制作步骤 (13)4．备份管理 (13)5．用户版本管理 (14)文档类别使用对象文档类别该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。
使用对象该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。
未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言1.1目的本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。
1.2范围本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括：●版本标识方法●软件系统数据的存放●文档的修改控制●文档的备份制度1.3术语定义SCMSoftwere Configuration Management缩写SVMSoftware Version Management缩写文档一种数据媒体和其上所记录的数据。
配置管理标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
软件配置软件的具体形态在某时刻的瞬时影像。
配置项软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。
基线软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
1.4参考资料[1] 《事业部门版本管理工作标准》 SEPG V1.0[2] 《国强财务V60配置管理》财务产品部 V1.0[3] 《商业事业部版本管理规范》 V1.0[4] 《酒店事业部版本管理规范》 V1.0[5] 《财务产品部版本管理规范》 V1.0[6] 《PACS事业部版本管理规范》 V1.0[7] 《MRPII部版本管理规范》 V1.0[8] 《金融事业部版本管理规范》 V1.0[9] 《ERP部版本管理规范》 V1.01.5版序控制记录1.6版本更新记录*A - 增加M - 修改D - 删除2．版本管理2．1版本标识方法为了使工作规范化、统一化，研发本部各部门实行的版本标识管理方法分为：正式版本和特殊版本。
2．1．1正式版本公司在市场渠道上发行的正规版本。
以“V”开头，版本号放后。
版本号分3节：主版本号，次版本号和内部版本号，每节之间以小数点（.）间隔。
如V2.0.01表示主版本号为2，次版本号为0，内部版本号为01。
2．1．2特殊版本特殊版本是在正式版本的基础上，针对某客户开发的版本。
它与正式版本的不同之处在于问题不具有通用性和适应性，只符合该用户的实际使用情况。
该版本标识分为常规部分和扩展部分，常规部分表示该特殊版本哪一个正式版本的分支，命名方法同正式版本的命名方法。
对于扩展部分，以“S”开头，后加一唯一序号。
举例如下：V2.33.S01 表示由V2.33分支出的第一个特殊版本V2.33.S02 表示由V2.33分支出的第二个特殊版本事业部不鼓励产生特殊版本。
只有在极特殊的情况下，才产生适当的特殊版本。
并在以后的版本演化中，尽量将其纳入到正式版本中。
2．2目录结构由于各部门的实际情况不同，目录结构很难统一，但为了能更好地管理各事业部的文档，建议可将被管理的配置项分为三大类：文档类、源码类及安装盘类，这样存放比较清晰，有利于版本管理。
至于二级目录是以模块划分还是以版本划分，各产品部、事业部可根据自己部门的情况，制定适合本部门的目录结构，并根据制定的目录结构给出文件级目录清单（先给出源程序及文档的文件级目录清单，安装盘的可以后再执行）：。
现以财务产品部V6。
0的目录结构举例如下：表示正式版本及特殊版本的目录按以下原则定义：（1）正始版本：以“V”开头，版本号放后，主版本号和次主版本号之间的“.”去掉，明细版本号之前加“-”。
举例如下：版本号目录名V6.0 V60V6.1 V61V6.0.01 V60-1V6.1.02 V61-2（2）特殊版本：目录名分为常规名和扩展名两部分，常规部分表示该特殊版本是由哪一个正始版本分支而来，命名方法同正始版本的命名方法。
对于扩展名，以“S”开头，后加一唯一序号。
举例如下：目录名意义V60.S01 表示由V6.0分支出的第一个特殊版本V60.S02 表示由V6.0分支出的第二个特殊版本V60-1.S01 表示由V6.0.01分支出的第一个特殊版本（3）对于有些事业部是针对某个具体用户开发的特殊版本，在表示特殊版本的目录时，常规部分表示该特殊版本是哪一个正始版本的分支，对于扩展部分，可以把项目名称作为扩展名。
举例如下：V60.中信表示由V6.0分支出的中信版本2．3文档的存放2.3.1 当前版本和历史版本的存放对于源码文件，特别增加了一个Current目录，存放当前正在开发与维护的源码文件，当前未发布版本的所有数据都存放在.....\CURRENT\下。
一旦当前版本正式发行，则当前目录被修改为相应的历史目录。
历史版本是指已经发行的版本，存放在相应的版本目录之下，一般不允许改动。
2.3.2 开发文档的存放根据各部门自己的情况，将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下，也可将不同模块的开发文档存放于不同的模块中。
2.3.3 源代码的存放源代码包括如：PBL，PBR，BMP，ICO，CPP，HPP，MAK，PRJ，INI等相关文件，是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件；联机帮助文件HLP在未生成HLP文件之前的DOC，RTF等格式的文档也视为源代码。
各子系统当前的程序源文件放入相应的目录下。
对于一个子系统又分多个分子系统的情况，应在该目录下分别建立几个相应的目录。
2.3.4 SQL语句的存放各子系统SQL文件放入…..\.......\SQL下，对于不同的数据库，分别建立不同的子目录，如WAT、SYB、MSS、ORC、DB2等。
公共SQL文件直接放入…\SQL下即可，不同数据库的特殊SQL分别放入对应的子目录下。
2.3.5发行文档的存放发行文档是指产品交付用户使用所必须的文件。
包括：产品可执行文件，用户使用说明书，联机帮助（HLP）；资源文件（BMP，ICO等），环境配置文件等。
以上文档作为制作发行盘的素材，放在RELEASE的REL_SRC目录之下，制作好的发行盘放在RELEASE的SETUP目录。
2．4权限控制管理为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。
文档权限类别：只读权限，读写权限。
文档类别：设计文档，源码，发行文档。
用户类别：开发人员、测试人员、分析设计人员、部门经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。
为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于各产品部、事业部的管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。
3．更新管理3．1源程序的修改当开发小组在开发同一产品时，应能保障：各成员间的修改不会互相覆盖；程序员的修改能及时反映到产品的最新版本中。
建议首先在相应子系统的下一级建一目录，如checkout，存放正在修改的文档及修改登记表。
当某个程序员要修改某一文档时，遵循以下程序：1、接收维护任务；2、查看需要修改的文件（如PBL及SQL等）是否正在被其它人员修改（检查checkout目录下是否存在要修改的文件或后缀已改为该程序员姓名简写）；3、如果有人在修改该文件，等待或与相应的开发员联系，重复2。
否则继续；4、将该文件复制到checkout目录下，在修改登记表中登记；或将该文件的后缀改为本人姓名简写；5、将该文件考至自己的私有目录；6、根据要求修改源文件；7、根据要求测试，并进行相关项的回归测试；8、交测试人员测试，如未通过，重复6。
如通过则继续；9、在checkout目录中删除该文件，并在修改登记表中标注修改完成；10、将修改完毕的文件通过电子邮件或其它手段送交版本管理员，版本管理员将文件复制到相应的路径；如遇特殊情况（版本管理员出差），程序员可将修改完毕的文件复制到相应的路径下，或将后缀改回正式。
11、回复下达者，报告维护任务完成。
驻外开发时，也采用以上程序进行控制。
3．2已发布版本的维护及修改在正式版本发布后，由于软件错误或其它问题（如用户提出增加小功能）需要对程序进行修改时，应及时作出修补盘（可以软盘或其它的形式），。
（1）在该发布版本目录下建立一该版本的修补目录，该目录由版本管理员负责。
（2）各系统如果修改了部分错误或增强了部分功能，应将修改或增加的编译后程序文件交由版本管理员，由管理员将该程序文件加入到该目录下，并更及时更新到安装盘中去。
（3）维护人员在更改产品的程序错误，如增加小的模块，或做小的改进时，应将程序文件及时通知版本管理员，由版本管理员负责更新源程序。
维护人员应详细记录修改内容。
举例如下：该表存放在相应版本的根目录下。
（4）修改过的源程序要经过测试人员的测试。
事业部如没有专人测试，可由程序员自己测试。
（5）对于涉级数据结构的程序变动，原则上不作为修补的内容，它只对某些用户有用，将可能在下一版本中体现，具体情况要具体处理。
3．3外出人员对产品的修改外出人员对产品的修改，是指以下几种情况：（1）外出维护时，需要对产品进行修改；（2）实施工程时，针对客户要求，对产品进行用户个性化修改（在这种情况下，一般需要衍生出特殊版本）。
执行程序：（1）维护人员每当接到实施或维护任务时，若需修改源代码，应在启程前认真填写源程序修改申请表，交部门负责人认定后，维护人员可携带源程序到用户现场。
（2）在维护期间，确实由于维护需要而必须在用户设备上拷入源程序时，应确保源程序的安全性，并及时予以删除。