软件版本号规则

版本号的格式：v<主版本号>.<副版本号>.<发布号>

版本号的初始值：v1.0.0

管理规则:

主版本号（Major version）

1. 产品的主体构件进行重大修改，主版本号加1；

2. 产品的主体构件之间的接口协议重大修改，主版本号加1。

副版本号（Minor version）

1. 主版本号变更时，副版本号置0；

2. 数据结构变更(新增或修改注释含义的情况除外)，副版本号加1；

3. 若副版本号累加至超过20时，采用主版本号进位制，主版本号加1，

副版本号重新置0。

发布号（Release）

1. 主版本号或副版本号变更时，Release号置0；

2. 若发布的版本无数据结构变更，则Release号加1。

举例说明：

在新版本推出时，应更新major、minor或是build（如有）的版号，决定于变更的大小。当有极大的更新时，会增加major的版号。而当有大更新，但不至于更新major时，会更新minor的版号。

若更新比较小，例如只是除虫（bug fixing），则会更新build的版号。以下是一个例子：1.0→1.0.1→1.0.2→1.1→1.1.1→2.0→2.1→2.1.1→3.0→…以上例子中，

1.0至1.0.1至1.0.2、1.1至1.1.1、

2.1至2.1.1都是小更新，例如bug fixing ,界面微调等；

1.0.2至1.1、

2.0至2.1都是较大的更新，例如增添了许多新的功能；

而1.1.1至2.0和2.1.1至3.0则是重大更新，例如app的界面或者功能完全发生变化。

文件命名和编号规则

文件命名和编号规则 1、纸质版文件的文件编号文件编号的编号规则是：产品型号--文件类型--版本号（0X-0Y即为版本VX.Y）例如，VQAC10II-HM-01-03，高压控制器产品型号VQAC10II，HM代表材料明细表，版本是V1.3的。 EKL4-HG-01-02，故障指示器产品型号EKL4，HG代表工艺文件，版本为V1.2的。 SENS-HY-01-01，传感器产品型号SENS，HY代表原理图，版本为V1.1。 DJGI200-HT-01，故障指示器产品型号DJGI-200，HT代表技术条件文件，版本为V1.0。一般情况下文件对应的代表字母如下： HS—使用说明书 HF—总体设计方案 HB—包装文件 HD—调试说明 HJ—总装配及零部件图电子版文件的文件编号和纸质版文件编号相同。 2、纸质版文件的索引编号索引编号的编号规则是：排序号--产品型号--此文件在此产品的所有文件中的排序号—版本号其中，排序号按照A故障指示器、B开路保护模块、C控制器、D电流源转换模块、E分界开关保护单、F雷电项目这六大产品类型分别进行整理。产品排序如下表1所示。例如，EKL4型故障指示器的工艺文件EKL4-HG-01-01 ，索引编号为：1（EKL4A产品在A故障指示器类产品中的排序）-EKL4（产品型号）-1（工艺文件在EKL4A产品所有文件中的排序）-V1.1（版本号）EKL4型故障指示器的技术文件/图纸更改通知单M R-4-3-(06)，1-EKL4-3-V1.0 MR-4-3-(06)，1-EKL4-3-V1.1 MR-4-3-(27)，1-EKL4-3-V1.2 DJGI200型故障指示器的工艺流程文件D JGI200-HG-01，索引编号为16-DJGI200-1-V1.0 调试文件DJGI200-HG-02，索引编号为16-DJGI200-2-V2.0 PSW200B型分界开关控制器的调试说明文件PSW200B-HD-01-01，索引编号为7-PSW200B-1-V1.1 项目/产品设计开发阶段评审表MR-7-3-(04)，索引编号为7-PSW200B-8-V1.0 HT-200 型分界开关控制器的检测报告文件没有编号，索引编号为1-HT200-5-V1.0 立项报告文件编号为201203，索引编号为1-HT200-6-V1.0 3、产品分类及编号 A-故障指示器 B-开路保护模块 C-控制器 D-电流源转换模块 E-分界开关保护单元 F-雷电项目 A2 C TEKL 光纤型CT供电故障指示器 A3 EKL3 故障指示器 A4 SFI 短路及接地故障指示器

软件版本管理规定

上海精佑通信技术有限公司企业标准（管理标准） 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）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。

软件版本管理规范标准[详]

软件版本管理规第一章目的本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 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.技术资料（保存项目技术文档，包括第三方技术资料等）

文件编号规范

保密级别：公司内部传阅范围：公司内部文件编号规范 20030311发布20030311实施

修改历史记录序号更改单号版本编制\日期审核\日期批准\日期

目录 1 目的 (4) 2 使用范围 (4) 3 编号办法 (4) 3.1 公司名称及项目名称约定: (4) 3.2 日期表示 (4) 3.3 文件版本编号 (4) 3.4 技术文件命名 (5) 3.5 其他文件的编号 (6) 3.5.1 公司规章制度和管理文件 (6) 3.5.2 合同协议 (6) 3.5.3 传真 (6) 3.5.4 电子邮件的命名规则 (7) 3.5.5 外来文件 (7) 3.5.6 对外发文 (7) 3.5.7 会议纪要 (7) 3.5.8 其它文件 (8) 3.5.9 文件附件 (8) 4 编号管理 (9)

1 目的确保公司重要文件具有唯一编号，便于文件的识别、追溯和控制，保证公司文件体系有效运转。 2 使用范围适用于公司文件的编号管理和控制： a)技术类文件：是指在公司的设计、生产、销售、服务等各个环节中与技术有关的各类文件和资料。 b)其他文件：包括公司规章制度、管理文件、合同协议、传真等； c)编号文件包括纸介文件以及电子文件。 3 编号办法 3.1公司名称及项目名称约定: 公司全称为：南非中国制衣集团(北京) 本组织简称：CGMBJ 项目全称：CGM 企业信息管理系统 1.0版项目简称：CGM v1 3.2日期表示格式：yyyy-mm-dd 或yyyymmdd yyyy:用四位数字表示公元年份，如2005表示公元2005年。 mm:用两位数字表示月份，不足两位时，第一位用零补齐，如03表示3月。 dd:用两位数字表示日期，不足两位时，第一位用零补齐，如15表示第15号。例如： 2003-10-27 或20031027 表示（2003年10月27日） 3.3文件版本编号下面是对文件版本进行编号要遵守的标准：起草版本的编号为0.1, 0.2, 0.3, ..., 0.10。版本编号可以根据项目需要延伸到若干层，例如，0.1, 0.1.1, 0.1.1.1. 一旦文件版本得以确认后，版本编号应该始自 1.0。版本编号不断变化为： 1.0, 1.1, 1.2, ..., 1.10。项目可以根据需要将版本编号晋升为2.0，2.1, 2.2 等。

版本发布命名规范

1. 1.版本命名规范软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release 2. 2.软件版本阶段说明 Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 Alpha ：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。 Beta ：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。 RC ：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。 Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。 3. 3.版本号修改规则

（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目决定是否修改。（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。（3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。（4）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。（5）希腊字母版本号：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 4.版本发布周期（1）非紧急情况：首先由测试人员测试并提交Bug，其次开发人员会尽量在当天修复Bug并在第二天发布该版本的alpha版，然后由测试人员测试验证关闭Bug之后在第三天会发布该版本的 beta 版。紧急情况：如果Bug比较紧急可跳过一般流程，由开发人员尽快修复Bug，测试确认之后直接发布该版本的 beta版。 5. 5 5 .版本号修改举例说明如此时版本号为：1.0.0.0321_alpha ，此时为内部测试阶段（1）开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： 1.0.0.0321_beta ，如当前日期跟上一个版本号的日期不一样，版本号可改为：1.0.0.0322_beta。（2）如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版，如1.0.1.0322_beta，日期为发布的当前日期。

文件编号规则86298

QCT/WJ-ZH-GZ-1801-001 文件编号规则 1.目的确保公司重要文件具有唯一编号，便于文件的识别、追溯和控制，保证公司文件体系有效运转。 2.适用范围适用于本公司经营管理过程中，所涉及的全部文件的编号、版号以及分发编号的标识管理。 3.总则 1. 凡本公司需进行编号管理的文件、资料，在编号时均应按照本规定的要求接受管理；本规定不适用于党务文件。 2. 由综合部负责制订公司文件分类的编号方法，并指导各部门专职人员执行。 3. 根据文件类型和内容进行编号分类，便于科学管理和开发利用。 4. 文件类别 4.1 文件 1. 管理制度 2. 技术文件 3. 合同(招投标) 4. 外来文件 4.2记录

1.会议记录 2.检查记录 3.工作总结(周报、月报) 4.工作计划 5.文件编号规则 5.1编码元素使用规则 5.1.1公司名称公司全称：XXXXXX有限公司简称：QCT 5.1.2部门代号 CW--财务部ZH--综合部XM--项目部GC--工程部YX--营销部 5.1.3日期代号统一采用“yyxx”的格式，例如“1801”代表该文件是2018年1月制定的。 5.1.4流水号统一采用三位阿拉伯数字编码，例如：“001”代表第一份文件。 5.1.5文件版本编号vdd 下面是对文件版本进行编号要遵守的标准：起草版本的编号为0.1, 0.2, 0.3, ..., 1.0。版本编号可以根据项目需要延伸到若干层。例如，0.1, 0.1.1, 0.1.1.1。一旦文件版本得以确认后，版本编号应该始自1.0。版本编号不断变化为：1.0, 1.1, 1.2, ..., 1.10。项目可以根据需要将版本编号晋升为2.0，2.1, 2.2 等。 5.2文件编码结构

项目软件版本号管理规范

历史修改记录一. 目的

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。

版本号命名规范

版本控制比较普遍的 3 种命名格式 : 一、GNU 风格的版本号命名格式 : 主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Num ber]] 示例 : 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式 : 主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Numb er]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Num ber]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于 0 的整数。应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。版本号管理策略一、GNU 风格的版本号管理策略：

文件编号规则

1目的 1.1为了使公司内部的管理体系文件统一协调，达到规范化和标准化要求,对文件编号、版本变更、部门代码及文件分发编号等做出管理规定。 2范围 2.1本管理规定适用于与正裕工业有限公司管理体系有关的文件编号的管理。 3定义 3.1无 4涉及部门 4.1所有部门 5一般原则 5.1质量手册的编号原则 5.1.1质量手册的编号为：A DD QM-流水号 ADD——公司英文名称 QM——质量手册的英文缩写流水号——从01至99 5.1.2版本：第一次出版，版本号为“A”，二版为“B”，依次类推 5.1.3版次的修改状态号，用0至9的阿拉伯数字表示。 5.2程序文件/作业指导书/管理规章制度/通告/作业流程的编号 5.2.1ADD□□□-部门代号-X X X □□□——文本格式代号； XXX——文件流水号（从001至999）； 5.2.2文本格式类别： PCD——程序指导书；WKI----作业指导书；RNC----管理规章制度；NTC----通告；FLW----作业流程； 5.2.3部门代码：

5.3 5.3.1表格编号格式为：A D D-部门代码-流水号/版本号 ADD——公司名称的英文缩写； F——表格的英文缩写；流水号——从001至999；版本号——首版为“A”，二版为“B”，依次类推； 5.3.2以上的表格编号为程序文件附表以外的编号，程序文件的表格编号规则见《程序文件编写程序》。 5.4外来文件的编号为： 5.4.1FD-类别-流水号/□□-原标准号（YYYY/MM/DD） FD——外来文件的英文缩写； □□——外来文件来源处或客户的缩写； 5.4.2注：外来文件的类别缩写： TN---技术标准类；AM---行政管理类；CM---客户资料类；OT---其他类文件。 5.4.3外来文件来源处名称为客户名称的两位英文或汉语拼音缩写； 5.4.4入库年月日作为外来文件的文件版号。 5.5各类外来文件的流水号为各自独立的流水系列。 5.6传真、会议记录等编号： 5.6.1编号格式为： A D D/□□□-部门代码-Y Y/M M/D D-流水号 ADD——公司英文缩写；

软件版本管理规范标准

软件版本管理规 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产品软件版本命名产品软件版本的命名规则如下所示：

软件项目版本号的命名规则及格式2016

软件项目版本号的命名规则及格式版本控制比较普遍的3 种命名格式: 一、GNU 风格的版本号命名格式: 主版本号 . 子版本号[. 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Nu mber]] 示例: 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式: 主版本号 . 子版本号[ 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Nu mber]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Nu mber]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于0 的整数。应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序(Hotfix) 更新。版本号管理策略一、GNU 风格的版本号管理策略：

软件版本管理规范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

(完整版)技术部软件版本管理规范

技术部软件版本规范文档建立/修改记录：版本管理规范【新建项目版本管理部分】 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.2.角色与职责所有项目成员都必须遵照版本控制规程操作配置库 1.3.配置项状态变迁规则配置项的状态有3种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。配置项状态变迁如图所示：配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。 1.4.配置项版本号规则配置项的版本号与配置项的状态紧密相关。 ?处于“草稿”状态的配置项的版本号格式为：0.YZ。YZ数字范围为01－99。随着草稿的不断完善，“YZ”的取值应该递增。“YZ”的初值和增幅由项目组成员自己把握。 ?处于“正式发布”状态的配置项的版本号格式为：X.Y。X为主版本号，取值范围为1－9。 Y为次版本号，取值范围为0－9。配置项第一次“正式发布”时，版本号为1.0。如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。

处于“正在修改”状态的配置项版本号格式为：X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。 1.5.版本控制的主要步骤 1.5.1.创建配置项项目成员依据《配置管理计划》，在配置库的开发库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ。 1.5. 2.修改处于“草稿”状态的配置项项目成员使用配置管理软件的Checkout/Checkin功能，可以自由修改处于“草稿”状态的配置项（不受变更控制规程约束），版本号格式为0.YZ。 1.5.3.评审和CCB审批配置项定稿后要接受评审和CCB审批。 1.5.4.配置项入基线库配置项通过评审和CCB批准后，由配置管理员纳入基线库，则配置项的状态从“草稿”变迁为“正式发布”，版本号格式为X.Y。 1.5.5.版本发布基线库里有新的配置项产生，或者基线库里的配置项版本升级时，配置管理人员要做版本发布，通过会议或EMAIL等方式通知项目组内其它人。通知中需要指明配置项在配置管理库中的目录名、文件名、版本号。

项目文档命名规则和格式要求

项目文档命名规则编制：日期：____/____/____ 审核：日期：____/____/____ 批准：日期：____/____/____

XXXX公司二零一五年五月制

历史记录

目录 1 目的 (5) 2 适用范围 (5) 3 术语和缩略词 (5) 4 规程 (5) 4.1 文档命名规则 (5) 4.2 配置项的版本标识 (9) 4.3 标签的命名 (10)

1 目的本文的目的是定义各项目所有相关文档和CMM要求的过程文件的格式和规则，以及配置管理中对配置项和版本的标识。 2 适用范围本规则适用于所有需求、设计等文档和过程文件。 3 术语和缩略词无 4 规程 4.1 文档命名规则 1组织标准软件过程文档编号 (1)过程文件格式：XXX-P-××，初始编号为：XXX-P-01，最大编号为：XXX-P-99。 (2)指南文件编号：XXX-G-××××，前两位××为指南所对应的过程文件编号。 (3)模板文件编号：XXX-T-××××，前两位××为指南所对应的过程文件编号。 2产品命名规范 (1)中文命名规范：中文全称V产品版本号。英文命名规范：首字母大写V产品版本号。3项目文档编号 (1)编号规则分三种： 1)单个文档：首字母大写V产品版本号-阶段英文缩写-文档名称英文缩写。 2)多个子文档：首字母大写V产品版本号-阶段英文缩写-文档名称英文缩写—流水号。 3)周期性：首字母大写V产品版本号-文档名称/英文名称-八位日期。 (2)项目阶段及文档名称英文缩写，见下表：

4文档版本 (1)格式：V×××.×××，初始版本号为V0.1，最大版本号为：V999.999。其中，草稿状态的版本均为V0.×××，例如：V0.1，V0.2……V0.999；而经过评审通过的文档版

软件版本定义规则

软件版本定义规则 1引言 1.1编写目的本文档作为本公司开发部测试部各项目组在进行软件设计、开发、测试时进行版本定义的指导性规则。 1.2定义和限制软件版本号为形如A.B.C.D的由”.”所间隔开的4段字符组成。其中A、B、C段为从0开始的整数，D段为从0开始的整数或者整数加英文字符的形式。 2定义规则在任何项目中，符合以下条件的模块需要独立维护版本： ?客户端和服务器端程序需要分开进行版本维护； ?可以独立运行并完成主要设计功能的模块； ?完成某些特定功能的接口程序或模块； ?其他必要的模块 2.1何时更改在项目进行到以下进程时，需要更改软件版本号： ?测试中FIX了部分缺陷需要提交测试时； ?公开发布或者需要提交给用户时； ?增加或更改了系统需求，软件重新进行开发时； ?更改了系统的设计框架、重新进行开发时； 2.2如何更改 ?普通项目的所有模块初始软件版本号为0.0.0.1，如是从原有系统上升级或其他特殊原因可更改为其他初始版本号。 ?在每次提交测试时，需要更改软件版本号的D段，从1开始递增，特殊情况时可在D段整数后面增加英文字符作为标识。 ?每次公开发布或者提交给用户时，需要更改软件版本号的C段，从0开始递增；同时将D段归0。因此所有D段为0的版本应该都是公开发布版本。 ?在原有总体设计上增加部分系统需求时，需要更改软件版本号的B段，从0开始递增，同时将C、D段归0。

?总体设计上有更改或者主要的功能模块设计上有变化，则可以更改软件版本号的A 段，从0开始递增，同时将B、C、D段归0。规则表如下：示例： ?假设原有版本为1.3.1.6， ?在下次提交新的测试版本时，版本号应升级为1.3.1.7； ? 1.3.1.7测试通过后需要对用户发布，则应该将版本升级为1.3.2.0； ?此时又修改了部分测试中发现的缺陷，并重新提交测试时，版本号应该升级为1.3.2.1； ?再次重新提交测试的版本号应该为1.3.2.2； ?如果用户经过试用，提交了部分新的需求，经过我们的重新修改部分编码，再次提交测试，则测试时的版本号应该升级为1.4.0.1； ?测试通过后提交给用户的版本号应该为1.4.1.0； ?如果由于设计上的缺陷，系统需要重新设计和编码，进行了比较大的改动，并提交测试，则测试时的版本号应该升级为2.0.0.1。

代码版本管理规范_v1.1

XXXXXXXX 代码版本管理规范

历史版本

目录历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)

1引言 1.1目的为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。

2现状概述目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试

(完整版)公司文件编号规则

中电新源文件编号规则 1. 目的加强公司文件的标准化管理，便于文件的识别、追溯和控制，规范存档，确保公司重要文件具有唯一编号，保证公司文件体系有效运转。 2. 适用范围适用于公司文件的编号管理和控制。 a)技术类文件：是指在公司的研发、生产、销售、服务等各个环节中与技术有关的各类文件和资料。 b)其他文件：包括公司规章制度、管理文件、合同协议、传真等； c)编号文件包括纸介文件以及电子文件。 3. 编号办法 3.1 公司名称约定公司全称：中电新源智能电网科技有限公司简称：CPHV 3.2 日期表示格式：yyyy-mm-dd yyyy:年份：用四位数字表示公元年份，如2012表示公元2012年。 mm月份：用两位数字表示月份，不足两位时，用零补齐，如03表示第3月。dd 某日：用两位数字表示当日，不足两位时，用零补齐，如05表示第5日。例如：2012-10-12表示（2012年10月12日） 3.3 文件版本编号下面是对文件版本进行编号要遵守的标准：起草版本的编号为0.1, 0.2, 0.3, ..., 0.10。版本编号可以根据项目需要延伸到若干层，例如，0.1, 0.1.1, 0.1.1.1. 一旦文件版本得以确认后，即正式版本编号应该始自1.0，版本编号不断变化为：1.0, 1.1, 1.2, ..., 1.10。项目可以根据需要将版本编号晋升为2.0，2.1, 2.2

等。 3.4 技术文件命名格式：CPHV-TT-NN-YYYY-MM CPHV：公司名称缩写 TT文件类型： SC：质量手册 CX：程序文件 JS：作业指导书、说明书等 GL:操作规程，计算书等 ZD：制度 JL：记录 NN：版本号，参见3.3节 YYYY-MM：年月 3.5 其他文件的编号 3.5.1 公司规章制度和管理文件公司规章制度和管理文件的编号格式为：CPHV(-DN)-TT-nnn-dd-YY DN：大写英文字母，部门代号，如该制度是公司级文件，适用于公司全体人员，该部分编码省略；如该文件是部门内部管理制度，则应标记部门编号，表示该制度由部门内部使用。相应的部门代号如下：质量部QM 综管部：ZG 生产部：SC 工程部：GC 研发部：YF 市场部：XS 财务部：CW

版本号命名规则

版本命名规范 1. 版本命名规范软件版本号由四部分组成：第一个1为主版本号第二个1为子版本号第三个1为阶段版本号第四部分为日期版本号加希腊字母版本号希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.0.0.081015_release 常规：完全的版本号定义，分三项：：<主版本号>.<次版本号>.<修订版本号>，如 1.0.0 2. 版本号定修改规则主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 3. 文件命名规范文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：rongliaoRCS 1.0.0.081015_release.apk，此文件为项目外包平台的测试报告文档，版本号为：1.0.0.081015_release。

文件编号规则

云南方策科技有限公司文件编号标准一、目的为确保公司文件具有唯一编号，便于文件的识别、追溯和控制，保证公司文件体系有效运转，特制定本标准。二、适用范围本标准适用于本公司经营管理过程中，所涉及的全部文件的编号、版号以及分发编号的标识管理。三、总则（一）凡本公司需进行编号管理的文件、资料，在编号时均应按照本标准规定的要求接受管理。（二）行政部负责制订公司文件分类的编号方法，并指导各部门专职人员执行。（三）根据文件类型进行编号分类，便于科学管理和开发利用。四、文件编号规则（一）编码元素使用规则 1、公司名称公司全称为：云南方策科技有限公司公司简称为：ACE 2、部门标识代码部门标识代码统一使用英文简写，如下：

3、日期代号格式： yyyymmdd yyyy：用四位数字表示公元年份，如2016表示公元2016年。 mm：用两位数字表示月份，不足两位时，第一位用零补齐，如01表示1月。 dd：用两位数字表示日期，不足两位时，第一位用零补齐，如20表示第20号。例如： 20160120 表示（2016年01月20日） 4、流水号统一采用两位阿拉伯数字编码，例如：“01”代表第一份文件。 5、版本编号下面是对版本进行编号要遵守的标准：起草版本的编号为 0.1, 0.2, 0.3, ..., 0.9，版本编号可以根据项目需要延伸到若干层，例如， 0.1, 0.1.1, 0.1.1.1。一旦版本得以确认后，版本编号应该始自 1.0，版本编号不断变化为： 1.0, 1.1, 1.2, ..., 1.10。（二）文件分类编码规则 1、管理类文件公司管理类文件的编号格式为：XX-DN-TT-dd-nn。格式说明：公司简称-部门代号-文件类型-文件版本号-流水号。 XX:公司简称。 DN：大写英文字母，部门代号，如该管理文件是公司级文件，适用于公司全体人员，该部分编码省略；如该文件是部门内部管理文件，则应标记部门编号，表示该文件由部门内部使用。 TT：文件类型，用大写中文字母简写表示, 如: ZL：质量手册 XU：程序文件 LC：工作流程 BZ：工作标准