软件项目版本号的命名规则及格式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 风格的版本号管理策略：

1．项目初版本时，版本号可以为0.1 或0.1.0, 也可以为1.0 或1.0.0，如果你为人很低调，我想你会选择那个主版本号为0 的方式；

2．当项目在进行了局部修改或bug 修正时，主版本号和子版本号都不变，修正版本号加1；

3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加1，修正版本号复位为0，因而可以被忽略掉；

4．当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加1；

5．另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。

二、Window 下的版本号管理策略：

1．项目初版时，版本号为1.0 或1.00；

2. 当项目在进行了局部修改或bug 修正时，主版本号和子版本号都不变，修正版本号加1；

3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加1，修正版本号复位为0，因而可以被忽略掉；

4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加1；

5. 另外, 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。

另外，还可以在版本号后面加入Alpha、Beta、Gamma、Current、RC (Release Candidate)、Release、Stable 等后缀，在这些后缀后面还可以加入1 位数字的版本号。

对于用户来说，如果某个软件的主版本号进行了升级，用户还想继续那个软件，则发行软件的公司一般要对用户收取升级费用；而如果子版本号或修正版本号发生了升级，一般来说是免费的。

=====附录软件版本名称=====

α（alphal）内部测试版

α版，此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug 较多，普通用户最好不要安装。

β（beta）外部测试版

该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要

经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。

γ（gamma）版

该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，尽可以装上一试。

trial（试用版）

试用版软件在最近的几年里颇为流行，主要是得益于互联网的迅速发展。该版本软件通常都有时间限制，过期之后用户如果希望继续使用，一般得交纳一定的费用进行注册或购买。有些试用版软件还在功能上做了一定的限制。

unregistered（未注册版）

未注册版与试用版极其类似，只是未注册版通常没有时间限制，在功能上相对于正式版做了一定的限制，例如绝大多数网络电话软件的注册版和未注册版，两者之间在通话质量上有很大差距。还有些虽然在使用上与正式版毫无二致，但是动不动就会弹出一个恼人的消息框来提醒你注册，如看图软件acdsee、智能陈桥汉字输入软件等。

demo 演示版

在非正式版软件中，该版本的知名度最大。demo版仅仅集成了正式版中的几个功能，颇有点像unregistered。不同的是，demo版一般不能通过升级或注册的方法变为正式版。

以上是软件正式版本推出之前的几个版本，α、β、γ可以称为测试版，大凡成熟软件总会有多个测试版，如windows 98 的β版，前前后后将近有10个。这么多的测试版一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量减少了软件中的bug 。而trial 、unregistered 、demo有时统称为演示版，这一类版本的广告色彩较浓，颇有点先尝后买的味道，对于普通用户而言自然是可以免费尝鲜了。

正式版，不同类型的软件的正式版本通常也有区别。

release 最终释放版

该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，对于用户而言，购买该版本的软件绝对不会错。该版本有时也称为标准版。一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号(r) ，如windows nt(r) 4.0、ms-dos(r) 6.22 等。

registered 注册版

很显然，该版本是与unregistered 相对的注册版。注册版、release和下面所讲的standard版一样，都是软件的正式版本，只是注册版软件的前身有很大一部分是从网上下载的。

standard 标准版

这是最常见的标准版，不论是什么软件，标准版一定存在。标准版中包含了该软件的基本组件及一些常用功能，可以满足一般用户的需求。其价格相对高一级版本而言还是“平易近人”的。

deluxe 豪华版

顾名思义即为“豪华版”。豪华版通常是相对于标准版而言的，主要区别是多了几项功能，价格当然会高出一大块，不推荐一般用户购买。此版本通常是为那些追求“完美”的专业用户所准备的。

reference

该版本型号常见于百科全书中，比较有名的是微软的encarta系列。reference是最高级别，其包含的主题、图像、影片剪辑等相对于standard和deluxe版均有大幅增加，容量由一张光盘猛增至三张光盘，并且加入了很强的交互功能，当然价格也不菲。可以这么说，这一版本的百科全书才能算是真正的百科全书，也是发烧友们收藏的首选。

professional（专业版）

专业版是针对某些特定的开发工具软件而言的。专业版中有许多内容是标准版中所没有的，这些内容对于一个专业的软件开发人员来说是极为重要的。如微软的visual foxpro标准版并不具备编译成可执行文件的功能，这对于一个完整的开发项目而言显然是无法忍受的，若客户机上没有foxpro将不能使用。如果用专业版就没有这个问题了。

enterprise（企业版）

企业版是开发类软件中的极品（相当于百科全书中的reference版）。拥有一套这种版本的软件可以毫无障碍地开发任何级别的应用软件。如著名的visual c++的企业版相对于专业版来说增加了几个附加的特性，如sql调试、扩展的存储过程向导、支持as/400对ole db的访问等。而这一版本的价格也是普通用户无法接受的。如微软的visual studios 6.0 enterprise 中文版的价格为23000 元。

其他版本，除了以上介绍的一些版本外，还有一些专有版本名称。

update（升级版）

升级版的软件是不能独立使用的，该版本的软件在安装过程中会搜索原有的正式版，如果不存在，则拒绝执行下一步。如microsoft office 2000升级版、windows 9x升级版等等。

oem版

oem版通常是捆绑在硬件中而不单独销售的版本。将自己的产品交给别的公司去卖，保留自己的著作权，双方互惠互利，一举两得。

单机（网络）版

网络版在功能、结构上远比单机版复杂，如果留心一下软件的报价，你就会发现某些软件单机版和网络版的价格相差非常大，有些网络版甚至多一个客户端口就要加不少钱。

普及版

该版本有时也会被称为共享版，其特点是价格便宜（有些甚至完全免费）、功能单一、针对性强（当然也有占领市场、打击盗版等因素）。与试用版不同的是，该版本的软件一般不会有时间上的限制。当然，如果用户想升级，最好还是去购买正式版。

Enhance 增强版或者加强版属于正式版

Free 自由版

Full version 完全版属于正式版

shareware 共享版

Release 发行版有时间限制

Upgrade 升级版

Retail 零售版

Cardware属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。

Plus 属增强版，不过这种大部分是在程序界面及多媒体功能上增强。

Preview 预览版

Corporation & Enterprise 企业版

Standard 标准版

Mini 迷你版也叫精简版只有最基本的功能

Premium -- 贵价版

Professional -- 专业版

Express -- 特别版

Deluxe -- 豪华版

Regged -- 已注册版

CN -- 简体中文版

CHT -- 繁体中文版

EN -- 英文版

Multilanguage -- 多语言版

软件系统命名规则(互联网+)

1、目的本指导书是为软件配置管理而制定。其目的是使公司软件产品配置标识的命名规范化。 2、适用范围适用于本公司所有软件产品的配置管理。 3、职责 4、控制内容 4.1、软件配置标识的组成 4.1.1、软件提供给用户的阶段产品和最终产品的配置标识由公司代码QW和以下五部分组成。 a、产品类别代码 b、产品（项目）标识或子系统标识 c、配置项标识 d、版本号其一般形式为：QWa-bbbb-cc-dd 4.1.2、软件开发过程中产生仅供公司或项目内部使用的配置项，其配置标识的一般形式为：bbcccccc-dd，其中，bb为产品（项目）标识缩写，cccccc为配置项标识，dd为版本号。 4.2、部门代码部门代码按《体系文件编号规定》4.3条的规定控制。 4.3、产品（项目）标识及其缩写产品（项目）标识由反映产品或项目名称的4~5位拼音字母组成，前2位字母为其缩写。如DHMIS是杭州大和热磁电子有限公司管理信息系统的项目标识，而DH则为其缩写。 4.4、子系统标识子系统标识由2位产品（项目）标识缩写和2~3位子系统名拼音字母组成，其中第3、4两位为子系统标识缩写。如DHXS是大和项目销售子系统的标识，而XS是其缩写。 4.5、配置项标识 4.5.1、4.1.1所述配置标识中的配置项标示：识（cc）如下表所配置项标识（cc）系统规格说明书FB 项目开发计划DP 软件需求规格说明书RS 概要设计说明书PD

详细设计说明书DD 用户手册UM 操作手册OM 源程序SP 4.5.2、4.1.2所述配置标识中的配置项标识（cccccc）有以下情况： a、配置项为数据项：配置标识由2位全局标识SY或子系统标识缩写（局部数据）和3位数字码组成。如SY001为001号全局数据的配置项标识 XS031为销售子系统031号数据的配置项标识。 b、配置项为数据流：配置项标识由2位子系统标识缩写，2位数据流标识DF和2位数字码组成。如ZCDF02为资财子系统02号数据流的配置项标识。 c、配置项为数据存储结构：配置项标识由2位子系统标识缩写，2位数据存储标识DB和2位数字码组成。如ZZDB01为制造子系统01号数据存储结构的配置项标识。 d、配置项为程序模块：配置项标识由2位子系统标识缩写，程序模块标识M和2~3位数字码组成。如XSM101为销售子系统101号程序模块的配置项标识。 e、配置项为存储媒体配置项标识由2位产品（项目）标识缩写或子系统标识缩写，2位存储媒体标识FD（软盘）、HD（硬盘）、CD（光盘）或TY（磁带）和2 位数字码组成。如ZZFD03为制造子系统的03号软盘。 f、配置项为测试计划配置项标识由2位产品（项目）标识缩写或子系统标识缩写，2位测试计划类别标识和2位数字码组成，其中，组装测试计划类别标识为 TP，确认测试计划类别标识为VP。数字码00表示产品（项目）或子系统的测试计划，其它数字则表示某一号分计划。如DHVP00为大和项目确认测试计划的配置项标识。 XSTP01为销售子系统01号测试计划的配置项标识。 4.6、版本号版本号由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，日期为发布的当前日期。

文件命名和编号规则

文件命名和编号规则 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 短路及接地故障指示器

软件版本命名规则

空蓝忍耐我很幸运！: ) 主页博客相册|个人档案|好友查看文章【规范】软件版本命名规范 2010-02-21 18:01 一、软件版本命名规范 1. 软件版本阶段说明 * Base 版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 * Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug 较多，需要继续修改。 * Beta 版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI 。 * RC 版: 该版本已经相当成熟了，基本上不存在导致错误的BUG ，与即将发行的正式版相差无几。 * Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release 不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。 2. 版本命名规范软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base 、alpha 、beta 、RC 、release 。例如：1.1.1.051021_beta 。 # 版本号定修改规则： * 主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。 * 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。 * 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 * 日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。 * 希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 # 文件命名规范文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告1.1.1.051021_beta_b.xls ，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta 。 3. 版本的协同作业如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告 1.1.1.051021_beta_b1.xls 当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：项目外包平台测试报告 1.1.1.051021_beta_b_LiuQi.xls 。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：项目外包平台测试报告 1.1.1.051021_beta_b_LiuQi 2.xls 关于软件版本划分的一些知识 | | | | 激活我的百度空间百度空间百度首页 lmhytr

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

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

软件项目版本号的命名规则及格式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 风格的版本号管理策略：

文件编号规范

保密级别：公司内部传阅范围：公司内部文件编号规范 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 等。

APP版本命名规范

APP版本命名规范 2016/11/18 ALEX 1.版本号构成说明 APP版本号由四部分组成，中间用英文字符“.”连接。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号。版本号为阿拉伯数字0-9，希腊字母版本号共有五种，分别为base、alpha、beta、RC、release。举例：V1.2.3.20161118.beta。其中1代表主版本号，2代表次版本号，3代表修订版本号，20161118代表日期版本号，beta代表希腊字母版本号。 2.APP版本阶段说明 A.Base：此版本表示该APP仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 B.Alpha：APP的测试版本。该APP在此阶段以实现功能为主，通常只在APP开发者内部交流。一般而言，该版本bug较多，需要继续修改。测试人员提交bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将APP版本标注为alpha版。 C.Beta：该版本相对于Alpha版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是APP的UI。修改的的bug经测试人员测试确认后可发布到外网上，此时可将APP版本标注为beta版。 D.RC：该版本已经相当成熟，基本上不存在导致错误的bug，与正式版本相差无几。 E.Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。 3.版本号修改规则初始版本号：V1.0.0.20161117.alpha，此时为内部测试阶段。 A.希腊字母版本号：此版本号用于标注当前版本APP处于哪个开发阶段，当APP进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

软件版本管理规范标准

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

文件编号规则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文件编码结构

【项目管理知识】软件项目版本号的命名规则及格式介绍

软件项目版本号的命名规则及格式介绍版本控制比较普遍的3种命名格式: 一、GNU风格的版本号命名格式: 主版本号.子版本号[.修正版本号[.编译版本号]] 英文对照:Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Numb er]] 示例:1.2.1,2.0,5.0.0build-13124 二、Windows风格的版本号命名格式: 主版本号.子版本号[修正版本号[.编译版本号]] 英文对照:Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Numb er]] 示例:1.21,2.0 三、.NetFramework风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] 英文对照:Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Numb er]]

版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于0的整数。应根据下面的约定使用这些部分： Major：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序(Hotfix)更新。版本号管理策略一、GNU风格的版本号管理策略： 1．项目初版本时,版本号可以为0.1或0.1.0,也可以为1.0或1.0.0,如果你为人很低调,我想你会选择那个主版本号为0的方式;

文件编号规则

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——公司英文缩写；

OA办公系统流程命名规则

协同办公管理系统命名规说明目录一、流程分类规 (2) 二、流程命名规 (3) 三、环节命名规 (4) 四、流向命名规 (5) 五、角色命名规 (6) 六、字段命名规 (7)

一、流程分类规通常流程可以按照所属部门或业务类型来分类：

二、流程命名规命名规则（采用按业务流程分类的命名规则）： 2位业务类型代码+4位流水号+“-”+流程名称例如：财务管理流程类型下面，有费用报销的审批，则其命名应为：“CW0001-费用报销” 其中各字段含义如下：

三、环节命名规命名规则：[岗位/职位/角色]+环节动作例如：某流程的某环节需要采购部经理审批，那么该环节名称可以命名为：采购部经理审批；再如某流程的某环节需要总裁加签，那么该环节名称可以命名为：总裁加签，诸如此类。常用的环节动作有： 1、开始节点：拟稿、提交、发起、起草、申请、创建等。 2、中间节点：加签、接收、发布、处理、审批、审核、初审、终审、反馈、套红（公文、发文）等。 3、结束节点：完成、归档、结束等。

四、流向命名规命名规则：谓语+[环节名称]（如果下一环节为最后环节，则直接用环节名称）例如：呈交[审计总监审批]，退回[申请人起草]，归档常用的谓语有： a、呈交：文档流向上级领导办理 b、转交：文档流向平级或下级人员办理 c、退回：文档流向前面环节办理 d、转发：文档流向流程环节以外人员办理 e、知会：文档知会相关人员

五、角色命名规命名规则：原则上根据具体流程来命名角色。 1、流程专用角色：[流程编号]+岗位/职位 2、流程公用角色：[Public]+ 岗位/职位例如：[CW001]出纳，[IT001]系统管理员，[Public]总裁。

软件版本命名规范

软件版本命名规范(如1、0、0、1各代表什么意思) 1、软件版本阶段说明 * Base版: 此版本表示该软件仅仅就是一个假页面链接,通常包括所有的功能与页面布局,但就是页面中的功能都没有做完整的实现,只就是做为整体网站的一个基础架构。 * Alpha版: 此版本表示该软件在此阶段主要就是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改。 * Beta版: 该版本相对于α版已有了很大的改进,消除了严重的错误,但还就是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像就是软件的UI。 * RC版: 该版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发行的正式版相差无几。 * Release版: 该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,就是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的就是符号(Ｒ)。 2、版本命名规范软件版本号由四部分组成,第一个1为主版本号,第二个1为子版本号,第三个1为阶段版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。例如:1、1、1、051021_beta。 # 版本号定修改规则: * 主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定就是否修改。 * 子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定就是否修改。 * 阶段版本号(1):一般就是 Bug 修复或就是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定就是否修改。 * 日期版本号(051021):用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定就是否修改。 * 希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定就是否修改。 # 文件命名规范文件名称由四部分组成:第一部分为项目名称,第二部分为文件的描述,第三部分为当前软件的版本号,第四部分为文件阶段标识加文件后缀,例如:项目外包平台测试报告1、1、1、 051021_beta_b、xls,此文件为项目外包平台的测试报告文档,版本号为:1、1、1、051021_beta。 3、如果就是同一版本同一阶段的文件修改过两次以上,则在阶段标识后面加以数字标识,每次修改数字加1,项目外包平台测试报告1、1、1、051021_beta_b1、xls 当有多人同时提交同一份文件时,可以在阶段标识的后面加入人名或缩写来区别,例如:项目外包平台测试报告 1、1、1、051021_beta_b_LiuQi、xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别,例如:项目外包平台测试报告1、1、1、051021_beta_b_LiuQi2、xls

OA办公系统流程命名规则

协同办公管理系统命名规范说明目录一、流程分类规范 (2) 二、流程命名规范 (3) 三、环节命名规范 (4) 四、流向命名规范 (5) 五、角色命名规范 (6) 六、字段命名规范 (7)

一、流程分类规范通常流程可以按照所属部门或业务类型来分类：

二、流程命名规范命名规则（采用按业务流程分类的命名规则）： 2位业务类型代码+4位流水号+“-”+流程名称例如：财务管理流程类型下面，有费用报销的审批，则其命名应为：“CW0001-费用报销” 其中各字段含义如下：

三、环节命名规范命名规则：[岗位/职位/角色]+环节动作例如：某流程的某环节需要采购部经理审批，那么该环节名称可以命名为：采购部经理审批；再如某流程的某环节需要总裁加签，那么该环节名称可以命名为：总裁加签，诸如此类。常用的环节动作有： 1、开始节点：拟稿、提交、发起、起草、申请、创建等。 2、中间节点：加签、接收、发布、处理、审批、审核、初审、终审、反馈、套红（公文、发文）等。 3、结束节点：完成、归档、结束等。

四、流向命名规范命名规则：谓语+[环节名称]（如果下一环节为最后环节，则直接用环节名称）例如：呈交[审计总监审批]，退回[申请人起草]，归档常用的谓语有： a、呈交：文档流向上级领导办理 b、转交：文档流向平级或下级人员办理 c、退回：文档流向前面环节办理 d、转发：文档流向流程环节以外人员办理 e、知会：文档知会相关人员

五、角色命名规范命名规则：原则上根据具体流程来命名角色。 1、流程专用角色：[流程编号]+岗位/职位 2、流程公用角色：[Public]+ 岗位/职位例如：[CW001]出纳，[IT001]系统管理员，[Public]总裁。

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

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

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；而经过评审通过的文档版

软件开发流程规范方案

软件开发流程规范 V1.0 德联软件有限责任公司

编制人：侯秀美审核人：2015 年8 月19 日

目录目录 0 一、概述 (2) 二、开发流程规范 (3) 2.1 系统软硬件开发环境 (3) 2.2 系统架构（系统组成） (5) 2.3 系统功能模块设计 (6) 2.4 系统功能开发流程图 (6) 2.5 开发修改记录 (7) 三、开发代码规范 (8) 3.1 文件结构 (8) 3.1.1 文件信息声明 (8) 3.1.2 头文件的结构 (10) 3.1.3 定义文件的结构 (11) 3.1.4 头文件的作用 (12) 3.1.5 目录结构 (13) 3.2 命名规则 (13) 3.2.1 共性原则 (13) 3.2.2 Windows变量命名规则 (14) 3.3 程序风格 (17) 3.3.1 空行 (17) 3.3.2 代码行 (18) 3.3.3 代码行内的空格 (19) 3.3.4 对齐 (21) 3.3.5 长行拆分 (22) 3.3.6 修饰符的位置 (23) 3.3.7 注释 (23) 3.4 函数设计 (26) 3.4.1 参数的规则 (26) 3.4.2 返回值的规则 (27) 3.4.3 函数内部实现的规则 (30) 3.4.4 其它建议 (32) 3.4.5 使用断言 (32) 3.4.6 引用与指针的比较 (33) 3.5 变量类型定义 (35) 四、软件测试规范 (36) 4.1 单元测试 (36) 4.2 系统测试 (37) 4.6 业务测试 (38)

4.7 验收测试 (38) 4.8 用户现场测试 (39) 五、软件版本管理 (39) 4.1版本管理的必要性 (39)

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

中电新源文件编号规则 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、RC，GA RC：就是Release Candidate（候选版本）的缩写 GA：就是General Availability，正式发布的版本 Alpha：内测版。 Alpha是希腊字母的第一位的英文谐音，就是α，用在软件版本中就是表示最初级的版本。通常情况下Alpha是内部测试版，一般不向外部发布，会有很多Bug。除非你也是测试人员，否则不建议使用。 Beta：公测版。 Beta是希腊字母的第二位的英文谐音，就是β，是一个比Alpha稍高的版本。Beta 也是一个测试版本，在正式版推出之前发布，主要用于面向公众进行测试及Bug收集，这个阶段的版本Bug可能较多，并且可能会加入一些新的功能。 Delux：豪华版。 Plus版和Delux版区别不大，比普通版本多了一些附加功能。 EVAL：体验版或评估版。功能上和正式版没有区别，但存在一些时间或空间上的限制。 Final：正式版。软件的正式版本，修正了Alpha版和Beta版的Bug。 Free：免费版。 Full：完全版。 OEM：是给计算机厂商随着计算机贩卖的，也就是随机版。只能随机器出货，不能零售。如果买笔记型计算机或品牌计算机就会有随机版软件。包装不像零售版精美，通常只有一面CD和说明书(授权书)。 Plus：加强版。 Pro：专业版。需要注册后才能解除限制，否则为评估版本。 RC(Release Candidate)：Candidate是候选人的意思，用在软件上就是候选版本，而Release Candidate 就是发行候选版本，也就是说这还不能算是正式的发布版。。

和Beta版最大的差别在于Beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而主要着重于除错! RTL(Retail)：零售版。正式上架零售版。 RTM(Release to Manufacture)：程序代码开发完成之后，要将母片送到工厂大量压片，这个版本就叫做RTM版。所以说，RTM版的程序码一定和正式版一样。 RVL：不详。 SR：修正版或更新版。修正了正式版推出后发现的Bug。 Trial：试用版。软件在功能或时间上有所限制，如果想解除限制，需要购买正式版。 ------------------------------------------------------------------------------- 另外： Build：不是一个发行版本，而是一个内部版本构建标号，用于周期性的生成目标程序，主要目的是构建程序进行测试及版本备份，并可以版本发布时进行选择，类似于RC版本。同一版本可以有多个Build号，通常Build后面的数字越大，软件版本越新。为了维护软件项目, 我们提出了对版本进行管理控制的要求. 而对于用户来说, 版本直接体现在版本号的命名上. 那么, 如何对版本号进行命名呢? 我查了许多的资料, 希望能解释得比较具体, 同时也希望您在阅读本文的时候, 能够对版本号的命名格式提出自己的见解, 这当然包括一些版本号命名的个例. 下面, 让我们看一下比较普遍的 3 种命名格式. GNU 风格的版本号命名格式: 主版本号.子版本号[.修正版本号[.编译版本号]] 英文对照: Major_Version_Number.Minor_Version_Number[.Revision_Number[.Bui ld_Number]] 示例: 1.2.1, 2.0, 5.0.0 build-13124 Windows 风格的版本号命名格式: 主版本号.子版本号[修正版本号[.编译版本号]]英文对照: Major_Version_Number.Minor_Version_Number[Revision_Number[.Buil d_Number]] 示例: 1.21, 2.0 .Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修