版本控制规范
版本控制规范
1.简介
1.1目的
版本控制规范用于确定软件配置项的命名与版本号管理的规则，以确保清楚地、唯一地标识软件的各个组成部分及其状态，并建立这些部分之间的一致性关系。
1.2范围
版本控制的范围包括：
?源代码：用计算机编程语言编写的源代码文件
?文档：需求文档、架构设计文档、数据库设计文档等描述软件功能和结构的技术文
档；项目计划等项目管理文档以及各种测试文档和用户文档
?产品包：将源代码进行编译得到的可运行的软件系统
2.产品标识
在每个软件产品立项时建立该软件产品的标识，以唯一地代表一个软件产品或项目，产品标识也称为项目标识。
产品中文名称
产品英文名称
产品英文简称
主版本号
次版本号
小版本号
Release 号
版本号
产品名称产品标识
2.1 产品名称
新产品立项时，为产品赋予产品名称；当已有产品升级时，则沿用前一版本产品的名称。 产品名称包括：
? 产品中文名称：如：订单管理系统，仓库管理系统等等
? 产品英文名称：如：Order Management System ，Warehouse Management System ? 产品英文简称：如：OMS ，WMS 产品名称用于相关文档的编写和产品的发布。
产品名称不是某一产品的唯一标识，必须与版本号一起用才能标识特定产品。
2.2 版本号
版本号用来标识开发、测试、交付阶段的不同状态的产品，版本号格式为：
<主版本号>.<次版本号>.<小版本号>-[Build 号]
? 主版本号：立项时设置，在整个项目开发过程中不改变 ? 次版本号：立项时设置，在整个项目开发过程中不改变
?小版本号：立项时设置，在整个项目开发过程中不改变
?Release号：又叫Build号，内部测试开始之前设置，初始值为0，此后每产生一次
小的修改，Release号+1
版本号的一般形式如：1.0.7-101，2.0.0-900
3.版本规范
3.1版本号设置规则
3.1.1主版本号
1、设置时间：产品立项时设置
2、设置规则：
?新产品立项，主版本号为1
?产品构架发生改变，主版本号+1
?产品主要组件（比如订单处理框架）进行重大修改，主版本号+1
?产品对外接口协议发生更改，主版本号+1
3.1.2次版本号
1、设置时间：产品立项时设置
2、设置规则：
?新产品立项，次版本号为0
?为处理产品Bug或改进现有功能/性能，对现有功能模块做大的修改，但不增加新的
功能模块，副版本号+1
?为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构件未做重大
修改，并且产品的主体构件之间的接口协议也未做修改，副版本号+1
?为适应不同用户需求，对产品进行更改，而产品的主体构件未做重大修改，并且产
品的主体构件之间的接口协议也未做修改，副版本号+1
?当主版本号变更时，副版本号同时置0
3.1.3小版本号
?新产品立项，小版本号为0
?修复Bug或改进现有功能，但不对现有功能模块做大的修改，不增加新的功能模块，
小版本号+1
?当次版本号变更时，小版本号同时置0
3.1.4 Build 号
1、 设置时间：产品开发结束，内部测试开始之前
2、 设置规则：
? Release 号初始值为0
? 测试过程中，每进行一次修改，Release 号+1
3.2 版本管理
SVN 版本变迁(版本号由MAVEN 管理)
trunk branche tags
阶段
项目A
1.0.0-SNAPSHOT
项目A 1.0.0.Release
项目A
1.0.1-SNAPSHOT
项目A
1.0.x-SNAPSHOT
项目A 1.0.x.Release
项目A 1.x.0.Release
合并
项目A
2.0.0-SNAPSHOT
项目A 2.0.0.Release
S
项目A
1.x.0-SNAPSHOT
合并
项目A 1.0.1.Release
3.2.1 trunk
任何时候trunk 里包含的都是最新的开发代码。 这里的代码将会工作到下一个主要发布版本。
trunk 应该只被用来开发将会成为你的下一个重要版本的代码。 不要给trunk 加上版本号和发布名称。 仅需要保证trunk 在任何时候都处于“开发模式”。
3.2.2 branches
有几种不同类型的分支。在branches的目录里，可以为更多具体的目标创建路径，像即将发行版本。Brahches可以包含了trunk在不同发展阶段的副本。
3.2.2.1 Release Branches
当trunk达到准备发布的阶段时（或者你想冻结新特色的添加时），应该创建一个release branches。Release branches只是当前trunk的一个副本。
这个branches可以被单独的签出，也可以启动branches和基于此版本的项目。还可以使用此分支在测试期间修复Bug。这种方式能够保证trunk继续开发，而不会被发布某个具体的版本所干扰。因此当准备发布一个新版本时，不会影响trunk增加新的功能。
3.2.2.2Bug fix branches
分支也可以用于处理trunk或release branches里发现的严重的Bug。这些Bug很复杂，不能在一次提交时就修复他们。因此为了集中精力修正此错误，应该为此问题创建一个新的分支。这样就不会影响trunk 和release branches的继续进行，并且也不会因为发现新的Bug 和测试而干扰此Bug 的修复。
3.2.2.3Experimental branches
有时想将某个新技术引进项目。但是不想影响到整个项目。比如想把web应用从spring3x改为spring4x。要花多少时间？在这期间trunk停止使用？直到把所有到spring 的转换做完。
可能Spring4x对程序变动较大，应该创建一个实验分支。这样就可以在分支里进行更改，如果失败了，不影响当前应用，实验分支可以抛弃。如果成功，可以很容易的将其合并到trunk。
3.2.3tags
tags用来备份代码，通常是readonly的，不被用来开发，只是用来标记代码的状态。
3.2.3.1 1.3.1 Release tags
Release Tags 标记版本发布点的代码。Release Tag 永远是相应发布分支的副本。Release Tag命名规则：版本号+“Release”后缀。
4.SVN使用规范
4.1先更新，再提交
SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。
如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。
4.2多提交
每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。提倡多提交，也就能多为代码添加上保险。
4.3不要提交不能通过编译的代码
代码在提交之前，首先要确保能够在本地编译。项目经理在准备项目工作区域的时候，需要确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
4.4每次提交必须书写明晰的标注
在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
4.5提交时注意不要提交本地自动生成的文件
例如eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，项目编译生成的临时文件.obj, .class等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。
4.6不要提交自己不明白的代码
代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。
4.7慎用锁定功能
在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。
5.目录结构
示例
https://www.wendangku.net/doc/fb17254877.html,
src winit2.0
seller-
portal trunk
branches
tags
src
oms
agile-
framework
...
mqx
docs
tms
wms
...
oms-spi
oms-server
版本控制流程规范V完整版
版本控制流程规范V HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
版本控制流程规范文档 目录 一、编写目的 本文档主要目的是规范配置管理活动的过程，阐述了在项目开发、测试、实施的过程中SVN库的组成和使用规约，指导使用者正确地操作SVN 库，以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 二、适用范围 该规范适用于公司内部所有项目的配置管理过程。 三、环境资源 在整个项目过程或产品生命周期中,选择SVN作为配置管理工具。
四、职责 五、规范 1，用户命名及权限配置 1)SVN用户命名 项目组成员在各自的PC上安装SVN客户端，根据配置管 理员所分配的用户和权限登录配置库进行各项配置管理活 动。 初始用户命名规则： 用户名：公司邮箱@前的部分
密码：手机号后6位 2)访问约定 为了保证各个项目组开发成果的安全性，以项目为单位， 进行了精确权限划分，使得成员只能操作该项目组内的配 置项。 内网访问svn资源库地址： svn: ... /svn/项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库，并具有特 定文件区域的读、写权限，配置管理员统一分配和管理权 限。 2，SVN库的划分 根据公司的项目，采用项目名—分区名—版本名—的主结构进行管理。 1)版本库名 根据项目名称由项目经理与配置管理员共同设定。各项目 统一建立2层目录，子目录根据实际情况建立。 2)文件结构 a)工作区：按版本存放提交测试阶段的相关程序、文档等 开发：开发相关 测试：测试相关
公司软件管理规范
XXXXXX有限公司 文件制订（修订、作废）申请单NO.: 表格编码：
1. 目的 为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序： 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软
件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表： 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）
软件版本管理规定
上海精佑通信技术有限公司企业标准 （管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施
上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)
上海精佑通信技术有限公司 文档版本变更记录： 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版 本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射 频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。
版本控制流程规范V0.1
版本控制流程规范文 V0.1 档
目录 一、编写目的 4... 二、适用范围 4... 三、环境资源 5... 四、职责 5... 五、规范 6... 1，用户命名及权限配臵........................................................... 6. . 1)SVN 用户命名 (6) 2)访问约定 (6) 3)权限管理 (6) 2，SVN 库的划分........................................................... 7. .. 1) 版本库名 (7) 2) 文件结构 (7) 3，版本控制........................................................... 8. .. 1) 控制流程 (8)
2) 变更流程 (9) 4，备份方案.......................................................... 1.. 0.
一、编写目的 本文档主要目的是规范配臵管理活动的过程，阐述了在项目开发、测试、实施的过程中SVN 库的组成和使用规约，指导使用者正确地操作SVN 库，以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 适用范围 该规范适用于公司内部所有项目的配臵管理过程。
三、环境资源 在整个项目过程或产品生命周期中,选择SVN 作为配臵管理工具。 四、职责
五、规范 1，用户命名及权限配臵 1)SVN用户命名 项目组成员在各自的PC上安装SVN 客户端，根据配臵 管理员所分配的用户和权限登录配臵库进行各项配臵管 理活动。 初始用户命名规则： 用户名：公司邮箱@前的部分 密码：手机号后6 位 2)访问约定 为了保证各个项目组开发成果的安全性，以项目为单 位，进行了精确权限划分，使得成员只能操作该项目 组内的配臵项。 内网访问svn 资源库地址： svn:https://... /svn/ 项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库，并具有 特定文件区域的读、写权限，配臵管理员统一分配和管 理权限。
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 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.技术资料（保存项目技术文档，包括第三方技术资料等）
测试流程版本管理规范标准[详]
测试流程、版本管理规 编制： 审核: 批准： 文件历史记录
目录 测试流程、版本管理规 (1) 1.目的 (3) 2.适用围 (3) 3.测试流程规 (3) 3.1搭建环境 (3) 3.2冒烟测试 (3) 3.3禅道版本管理规 (3) 3.4系统测试流程规 (4) 3.6 缺陷管理流程 (8) 3.4上线版本 (9) 4.系统版本管理规 (9) 1.目的 为了规项目组的测试流程、版本规，减少人为影响上线版本的质量 2.适用围 项目组所有系统以及流程的版本 3.测试流程规 3.1搭建环境 缺失本次版本变更说明或者部署文档不完整，需向开发人员说明，并要求提供齐全，保证文档有效性。
3.2冒烟测试 ?环境搭建完后，进行冒烟测试，如果冒烟测试不通过，需打回版本 ?如果未实现需求涉及的功能，打回版本（除非开发人员有说明按模块提交测试）3.3禅道版本管理规 产品 ?接到新的系统时，首先在产品模块新建产品名称，命名规则直接以系统名称为准，比如“移动OA” ?产品新建成功后，需要把需求关联至产品，可以直接把文档或者git地址关联进来 项目 ?新项目或者目前版本的变更时，需要新建项目，项目需要关联产品，命名规则直接以版本名称为准，比如“移动OA3.0” ?项目新建成功后，开发提交一次版本，需要把版本号进行维护，版本号命名规则。如“移动OA3.0_rc1”，以此类推，每一轮测试时，如果仍存在BUG,需要把下个版本号提前维护进来，方便开发变更BUG状态时，选择正确的版本号 测试 ?项目的模块需要分类维护，测试用例对应到模块下，每一轮测试完毕后，需要变更测试用例状态，并把测试用例与BUG进行关联 ?在测试过程中，如果测试用例有遗漏，需要补写 ?每一轮测试结束后，需要出测试报告
(完整版)技术部软件版本管理规范
技术部软件版本规范 文档建立/修改记录： 版本管理规范 【新建项目版本管理部分】 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。测试发邮件给
软件配置管理规范流程
1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理（Software Configuration Management，SCM） 软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项（Configuration Item，CI） 凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线（Baseline） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一
产品开发版本管理流程
版本管理流程 1.0目的 本流程旨在对产品版本实施有效的管理与控制，从而进一步实现产品开发的工程化和系统化，提高产品开发的质量管理水平，以保证产品开发的规范性和继承性。 2.0范围 本流程适用于开发设计的硬件产品、软件产品、产品的测试工具及顾客系统。 3.0定义 3.1版本 本文中的版本，包括如下几个范畴： ●内部验收通过后的实验版本，用于小批量试产及现场试验； ●正式验收通过后的正式版本。 3.2版本库 技术管理部版本管理员必须建立二个版本库，用以保存已正式运行的所有版本，以便发现问题时能及时进行问题的定位。这两个版本库为： (1)产品版本库：为满足一般顾客需求的版本。 (2)专用版本库：为满足某些顾客的特殊需求而定制的专用版本。这种版本应尽量减少， 当某些需求已成为一种较为普通的需求时，应考虑将该功能在通用版 本中实现。 为方便管理，开发部门在产品开发过程中可自行定义一些临时版本及建立本部门的开发版本库，开发部的临时版本库为开发版本库，技术支持部的临时版本库为顾客版本库。 4.0职责 4.1技术管理部版本管理员 4.1.1建立及管理产品版本库、专用版本库，控制版本的发行； 4.1.2控制版本的升级； 4.1.3负责发布产品的《版本说明及配套表》。 4.2开发部、技术支持部经理 4.2.1负责产品问题的定位； 4.2.2与项目组一起确定设计更改及工程更改方案；
4.2.3审核《设计（工程）更改报告》、《版本说明及配套表》及监督文档更新。 4.3项目组／项目负责人 4.3.1负责系统联调过程中问题的收集； 4.3.2负责产品的设计更改、工程更改并编制相应文档； 4.3.3负责对产品所作的更改进行测试并编制相应的文档。 4.4技术管理部测试组 负责对产品所作的工程更改进行验收测试并编制《验收测试报告》。 4.5总工程师 4.5.1负责批准设计更改申请和《设计（工程）更改报告》； 4.5.2负责批准《版本说明及配套表》。 4.6开发部门版本管理员 负责根据技术管理部分配的版本号及归档的技术文档对版本进行定义并编写产品的《版本说明及配套表》。 5.0流程提要 开发部门根据各方面反馈的产品质量问题，首先定位问题所对应的版本库及版本，然后确定相应的更改方案，在此基础上，根据具体情况进行设计的更改、测试、内部验收、小批量试产、现场试验及正式验收等阶段，开发出实验版本或正式版本，用于向市场发布。 6.0流程说明 6.1建立产品版本库、专用版本库 技术管理部的版本管理员根据项目情况建立产品版本库和专用版本库。 6.2根据反馈的问题定位相应版本库及版本，确定更改方案。 总工程师、开发部门及技术管理部版本管理员根据产品的《验收测试报告》、《产品小批量试产报告》、顾客反馈意见以及内部升级需求，针对所反馈的问题，定位相应的版本库及版本，对问题定位并确定设计更改或工程更改的方案，技术管理部版本管理员分配一个新的版本号，以、《预研（项目）任务书》及《研发任务书》的方式作为产品或系统更改、升级及换型的依据。 6.4设计更改及测试 开发部门根据《预研（项目）任务书》及《研发任务书》实施产品/系统的工程更改、升级及改型，之后进行单元测试、集成测试及系统联调测试，联调通过后修改相应的技术文档，编写《设计（工程）更改报告》等相应的技术文档。
项目软件版本号管理规范
项目软件版本号管理规范
历史修改记录 一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象， 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 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。
软件项目上线标准流程
项目上线部署发布流程
2017/9/14
一.目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。二.适用范围 适用于公司所有项目和产品 三.职责分工 开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库） 测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 四.发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 4.1.提交测试 ①开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试人员。 ②测试人员根据模块功能文档并制定测试方案，测试用例，特别注意临界点测试方案。 ③测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉
及数据库操作可提请DBA操作。 ④记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。 ⑤内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 4.2.预热发布 ①测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。 ②如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。 4.3.正式上线 ①在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。 ②确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。 ③运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。 ④发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。 ⑤紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决。测试通
软件版本管理规范19726
软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 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
【通用】软件版本管理办法.doc
信息系统软件版本管理办法
第一章总则 第一条为加强软件版本管理，规范软件版本管理工作流程，提高版本运行维护质量，保证信息系统安全可靠高效地运行，特制定本办法。第二条本办法涉及的软件包括在线运行的软件和拟投产的软件。软件版本管理对象包括应用软件版本以及相关操作系统、数据库、中间件等基础软件。 第三条软件版本管理是信息系统开发管理和日常维护管理工作的一个重要组成部分，本办法作为软件版本管理的重要依据，软件版本管理归口管理部门、业务支撑部门、风险管理部门、内审部门及各软件供应商要认真履行各自职责，严格执行软件版本管理的各项流程和规定，保障信息系统的安全稳定运行。 第四条任何未经版本归口管理部门许可的软件版本不允许在生产环境使用。在商务合同中若涉及信息系统软件版本，应确认为版本归口管理部门允许使用的软件版本。因使用未经许可的软件版本而造成系统故障影响正常业务交易，相关部门及各厂商要承担相应的责任。第五条本办法由信息技术部负责解释和修订，自发文之日起开始执行。
第二章组织与职责 第六条软件版本管理实行总行集中管理体系。 第七条信息技术部是信息系统软件版本的归口管理部门。 第八条稽核监控部是信息系统软件版本管理的内审部门。 第九条风险管理部是信息系统软件版本管理的风险控制部门。 第十条信息系统软件版本管理工作还涉及软件提供商，软件提供商包括软件最终提供商、代理商和维保服务商（以下简称厂商）。 第一节归口管理部门职责 第十一条归口管理部门负责制定和完善的软件版本管理办法。 第十二条归口管理部门负责制定信息系统软件版本管理工作的工作计划、工作要求和技术规范，并组织实施。 第十三条归口管理部门负责审批业务支撑部门上报的版本变更申请，组织进行资料审核和上线测试，安排试运行工作及全行推广实施。第十四条归口管理部门负责建立软件版本信息库，发布软件版本管理各类信息；建立版本预警体系，发布软件版本缺陷信息和版本预警信息。 第十五条归口管理部门负责与业务支撑部门、风险管理部门、内审部门、厂商协调信息系统软件版本管理的相关工作。 第三节业务支撑部门职责 第十六条版本管理业务支撑部门负责业务类需求的日常收集和集中
产品版本管理规范
基于Tortoise SVN的软件产品版本管理规范[草稿]
目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)
1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1. 目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档 一种数据媒体和其上所记录的数据。
版本控制工具使用规范.
版本控制与code review规范 目录 branch使用规则 (3 公共branch命名示例 (3 个人branch命名示例 (3 个人branch创建规则 (3 代码提交流程 (3 Windows平台文件夹方式操作与建议 (4 个人branch创建操作 (4 个人branch代码提交 (6 merge操作 (9 操作步骤1:合并branch (9 操作步骤2:解决冲突 (12 Eclipse 插件方式操作与建议 (14 Mac平台操作与建议 (21 1.采用CornerStone客户端进行SVN操作 (21 1、与服务器创建连接 (21
2、个人branch创建操作 (22 3、把服务器上个人branch 进行check out 到本地 (24 4、个人branch提交(commit操作 (25 5、merge操作 (26 2.采用终端命令提示符进行SVN操作 (28 1、将文件checkout到本地目录 (28 2、往版本库中添加新的文件 (29 3、将改动的文件提交到版本库 (29 4、加锁/解锁 (29 5、更新到某个版本 (29 6、查看文件或者目录状态 (30 7、删除文件 (31 8、查看日志 (32 9、查看文件详细信息 (32 10、比较差异 (32 11、将两个版本之间的差异合并到当前文件 (34 12、SVN 帮助 (35 13、版本库下的文件和目录列表 (35 14、创建纳入版本控制下的新目录 (36
15、恢复本地修改 (36 16、代码库URL变更 (36 17、解决冲突 (37 18、输出指定文件或URL的内容。 (37 branch使用规则 公共branch命名示例 branch-20150326-candidate 个人branch命名示例 branch-20150326-hulanlan branch-20150326-taskID 个人branch创建规则 ●开发人员基于每个开发小任务创建自己的branch, 以每天check in 自己的代码作备份。 ●基本原则是从最新代码创建branch,以方便未来的代码合并 ●原则是不直接在服务器上操作 代码提交流程 1.测试本地代码 2.整理本地代码, 申请code review 3.提交本地代码到个人branch
软件版本管理规范标准
软件版本管理规 V1.0.0 文档版本变更记录：
目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)
前言 为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。
软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件 已签订合同，有明确交付日期的产品。 2.3演示软件 处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示：
版本管理规范
版本管理规范 一、版本管理办法 1.1目的 按照一定的规则保存项目源程序的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到项目各个板块的任何版本。为保障公司源代码和开发文档安全不被泄漏，保证选代码的完整性，明确源代码控制管理流程，特制定此管理办法。 1.2适用部门 本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 1.3管理部门 源代码直接控制管理部门为软件部。 1.4控制范围 本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.5角色与职责 所有项目成员都必须遵照版本控制规则操作各个项目板块。 1.6版本管理工具Virsual SVN 用此工具对项目开始阶段的开发，和项目中期的变更进行版本的管理。避免发生版本丢失或混淆等现象，详细使用方法见：《Virsual SVN操作细则》 1.7项目各板块版本变迁规则 各板块的状态有3种：“草稿”（Dralt）、“正式发布”（Released）和“正在修改”（Changing） 各板块状态变迁如图所示： 各板块刚建立时其状态为“草稿”。各板块通过评审（试用）后，其状态变为“正式发布”。此后若更改各板块源代码，必须填写“版本变更情况表”及“版本变更状态跟踪表”，且版本状态变为“正在修改”，修改后通过审批（试用）其状态又为“正式发布”。以此循环。 二、SVN管理规范 2.1帐号密码的配发规则 根据岗位需要，针对不同人员，设置不同权限。遇岗位变更，随时增加删除权限。用户名：为姓名的‘姓’的全拼音+‘名’的开头拼音。 密码：一人一密码。 2.2上传文件注意事项 1.修改后的文件及文件夹的名字，跟修改前的必须同名，否则识别不了，当成新增
版本控制说明
Svn 版本控制 1、版本控制的必要性 版本控制(Revision control)是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。 就以软件开发来说，在开发过程中，利用svn进行版本控制可以帮助你记录你的开发过程，例如在某个时间段项目进行到了哪一步，还有哪些没有开发；哪些人参与了哪一模块的开发等，这样开发过程中如果出现问题也能够很快找到相应的负责人，得到最快解决，也能够及时协调开发过程中人力资源的合理分配。利用版本控制，可以有效地实现并行开发，不同的开发模块可以同时进行开发，防止重复开发和更改覆盖的现象，即使更改被覆盖也可以利用svn的恢复技术，恢复到未出错之前，能够减少开发风险。 利用版本控制开发的项目能够很容易的看出哪个是当前的最新的版本，以及每个版本的改进之处或者说解决了哪些问题，而且对于软件测试来说，版本控制能让你知道哪里改变了，以及代码的变化带来的影响，在知道具体内容后也就能省去一些无用的调试。 2、什么是版本控制？ 版本控制系统是一个当你在开发一个程序时存储你写的东西的所有修订版本的地方。 1）项目仓库 项目仓库是存储存储各种版本项目文件的主要地方，需要存储什么？一条判断准则：如果没有这个文件的最新版本，我们是不是可以构建、测试并交付我们的程序！ 2）版本编号：具体文件编号和项目仓库整体编号 3）项目、目录和文件 4）标签 5）分支 2、版本控制的实现方案 版本控制有两种实现方案： 一种是The Lock-Modify-Unlock Solution（锁-修改-解锁的解决方案）； 在这种方案下，每次只允许一个用户去进行修改，当用户要对文件进行修改时，必须先锁定该文件，此时其他用户就不能对文件进行修改了，只有当当前用户修改完文件，解锁该文件后，其他用户才能对该文件进行修改操作。 该方案有以下缺点： 1）一旦用户在修改完文件后忘记解锁该文件，那么其他用户将永远不能或者通过其他方法解除该锁后修改文件，这会造成延时或者资源浪费。 2）当一个用户只修改文件的前半部分，而另外一个用户修改文件的后半部分，他们所要操作的内容并没有交集，他们可以分别同时进行修改然后将修改内容合并，完全没有必要按先后顺序依次进行修改 3）安全性 另外一种是The Copy-Modify-Merge Solution（复制-修改-覆盖的解决方案），目前的版本控制软件主要是以后者为主，一些特殊情况下采用前者进行版本控制。
软件版本管理表格
XX公司软件版本控制办法 1、目的 规范本公司软件产品版本的升级流程，清晰管理软件版本号，保证各使用人、使用地点的版本软件都能胜任工作，并可靠保存不同版本软件。 2、适用范围 适用于研发结束进行测试或投入应用的软件系统、硬件驱动软件或独立工作软件，已销售产品中的软件系统的升级或变更管理等。 3、职责 3.1版本管理员负责统计公司内所有软件的版本信息，管理软件版本号，向软件工程师传达工程、维护及销售人员反馈的软件问题并进行汇总，在软件升级结束后向系统集成工程师提供新版本的软件系统。 3.2项目软件负责人及软件工程师负责对软件系统进行升级，项目软件负责人负责将升级后的软件上传到公司产品服务器，并通知版本管理员记录升级信息。 3.3每个项目的软件负责人对本小组内目前完成测试的软件及系统进行归档和版本维护。 3.4项目软件负责人对本项目的软件升级方法进行确认，将对软件的整体调整与总工协商后确定方法。 3.5销售人员和工程人员向版本管理员通报软件产品问题，工程人员负责升级后软件的重新安装和使用跟踪，并对修改版本软件的使用情况在规定时间内进行反馈。 3.6工程部集成工程师在完成软件安装后应填写客户版本信息清单，提交版本管 理员进行归档并汇总。 3.7 对于软件系统的一般性BUG和软件实现明显不适当的问题，项目软件负责人应积极进行修改，升级软件版本；其他软件使用性问题，项目软件负责人有权确定是否修改。 3.8对于软件功能性的重大修改，应将问题进行备案，并提交总工程师确定是否修改以及修改时间。对涉及需要产品升级等问题时，应提交公司技术委员会进行讨论确定。 4、工作程序 4.1软件系统保存 4.1.1建立公司产品存储服务器，网管（研发部）为每个项目组分配源代码存储区域，对每
某软件有限公司文档版本管理规范
密级：内控 研发本部版本管理规范 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术语定义 SCM Softwere Configuration Management缩写 SVM Software Version Management缩写 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确