软件产品版本号命名规范
版本命名规范
版本命名规范版本命名规范是指在软件开发过程中,为不同版本的软件定义一个规范的命名方式,以便于统一管理和识别各个版本。
版本命名规范通常包括以下几个方面的考虑。
1. 简洁明确:版本命名应该简洁明确,能够清楚地表达版本之间的差异和进展。
避免过长的命名,以免造成混淆。
2. 数字编号:版本命名一般采用数字编号,按照版本的先后顺序递增,例如1.0、2.0、3.0等。
这种方式简单直观,方便理解,特别适用于较小规模的软件项目。
3. 主次版本号:对于较大规模的软件项目,通常会同时使用主版本号和次版本号来表示不同的版本。
主版本号一般表示重大功能更新和改进,而次版本号表示一些较小的Bug修复和优化。
4. 补丁号:在次版本号下,可以再使用补丁号来表示一些小的修正和漏洞修复。
补丁号一般采用小写字母表示,例如 1.0.1、1.0.2等。
5. 预览版本:在软件开发过程中,常常会发布一些预览版本给用户测试和反馈。
预览版本可以使用Alpha、Beta等词语来表示,例如Alpha1、Beta2等,表示不同的开发阶段。
6. 发布日期:在版本命名中加入发布日期的信息,可以更方便地记录和追踪版本的更新历史。
日期格式一般采用YYYY-MM-DD的形式,例如1.0.1-2022-01-01。
7. 分支与主线:在软件项目中,常常会同时进行多个分支的开发,每个分支都有自己的版本号。
分支的版本号可以在主版本号后添加一个分支标识,例如1.0-branchA、1.0-branchB等。
8. 特殊版本:在一些特殊情况下,可能需要对某些版本进行特殊标记,例如重要的里程碑版本、稳定版本等。
这些特殊版本可以在版本号后面添加相应的标记,例如1.0-RC1、1.0-stable 等。
9. 向后兼容性:在更新版本时,尽量保持向后兼容。
如果新版本不兼容旧版本的接口或数据格式,可以将主版本号进行更新。
总的来说,版本命名规范应该便于管理和识别不同的版本,并充分表达版本之间的差异和进展。
软件版本命名规范及详细解释.docx
1、版本命名规范软件版本号有四部分组成,第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有五种,分别为base、alpha、beta 、RC 、release。
2、软件版本阶段说明Base:此版本表示该软件仅仅是一个基础功能,通常包括所有将要编写的功能,但是功能都没有做完整的实现,只是做为软件整体的一个基础架构。
Alpha:软件的初级版本,表示该软件在此阶段以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改,是测试版本。
测试人员提交Bug经开发人员修改确认之后,发布到测试xx让测试人员测试,此时可将软件版本标注为alpha版。
Beta:该版本相对于Alpha 版已经有了很大的进步,消除了严重错误,但还需要经过多次测试来进一步消除,此版本主要的修改对象是软件的UI。
修改的的Bug 经测试人员测试确认后可发布到外网上,此时可将软件版本标注为beta版。
RC:该版本已经相当成熟了,基本上不存在导致错误的Bug,与即将发行的正式版本相差无几。
Release:该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式的版本,是最终交付用户使用的一个版本。
该版本有时也称标准版。
3、版本号修改规则(1)主版本号:当功能模块有较大的变动,比如增加模块或是整体架构发生变化。
此版本号由项目决定是否修改。
(2)次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或增强。
此版本号由项目决定是否修改。
(3)修订版本号:一般是Bug 的修复或是一些小的变动或是一些功能的扩充,要经常发布修订版,修复一个严重Bug 即可发布一个修订版。
此版本号由项目经理决定是否修改。
(4)日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。
软件版本命名规范
产品经理、项目经理、开发工程师、配置工程师、配置管理员、产品/项目管理者。
2.3适用场合
软件研发及发布的版经理
负责软件版本的主版本号、发布版本号、补丁版本号、定制化
项目经理
项目经理负责过程版本号管理
配置管理员
配置管理员按规划的版本号进行相关的配置管理目录的创建
举例说明:
A.V1.0表示V1.0的第1个正式商用发布版本
5.相关文件
无
6.相关记录
无
PQA
审核版本命名是否符合《软件版本命名规范》
4.工作程序
4.1版本命名规则:
4.2规则说明:
1)主版本号:当功能模块有较大的变动,比如增加模块或是整体架构发生变化,此版本号由产品管理部决定是否修改,新产品主版本默认从1开始,当主版本升1时,次版本和阶段版本从0从新开始。
2)次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或增强。此版本号由产品管理部决定是否修改。新产品的次版本号默认从0开始,当次版本号升1,阶段版本号从0重新开始。
修改页
文件编号
修改条款
修改内容
修改人/日期
生效日期
编制
审核
分发部门会签
批准
□业务部
□研发部
□采购部
□生产部
□质量部
□行政部
1.目的
规范在研版本,补丁版本,基线版本的命名和管理。
2.范围
2.1概述
本规范定义软件版本的命名原则,编号定义,不同状态下版本遵循的命名要求等,包括过程版本、商用发布版本、试用版本、补丁版本、定制版本等。
软件产品名称命名规范
软件产品登记命名规则
1. 软件产品名称:软件产品名称构成品牌+产品用途与功能
+“软件”+产品版本号。
定制软件产品名称构成:品牌+客户单位名称+产品用途与功能+“软件”+产品版本号。
2. 品牌:品牌中须包含软件产品厂商标识,亦可含产品标识,
并可应用外文字母或拼音字母。
但在品牌中不可单独出现“中国”、“中华”、地方名等字样及其它专有名称。
3. 产品用途与功能:在本段中应以简明的方式表明该软件的运
用行业、用途与功能,不能笼统模糊,不准用全字母表示,如出现缩写须用括号标上,产品型号放在产品用途和功能前,不需加括号;国际公认的名称如LINUX、WINDOWS等可在该段中出现,不需用括号.
4. 产品版本号:软件产品的名称中必须表明VXX。
XXX字样的
版本号,其中X必须是具体数字,以年号和非标准式标明版本号的要做说明.
5. 软件产品外销名称可全用外文。
6. 该软件产品在办理著作权登记、产品测试和产品登记时名称
应一致。
软件版本号命名规范
1. 1.版本命名规范软件版本号有四部分组成,第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有五种,分别为base、alpha、beta 、RC 、 release2. 2.软件版本阶段说明Base:此版本表示该软件仅仅是一个假页面链接,通常包括所有的功能和页面布局,但是页面中的功能都没有做完整的实现,只是做为整体网站的一个基础架构。
Alpha :软件的初级版本,表示该软件在此阶段以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改,是测试版本。
测试人员提交Bug经开发人员修改确认之后,发布到测试网址让测试人员测试,此时可将软件版本标注为alpha版。
Beta :该版本相对于Alpha 版已经有了很大的进步,消除了严重错误,但还需要经过多次测试来进一步消除,此版本主要的修改对象是软件的UI。
修改的的Bug 经测试人员测试确认后可发布到外网上,此时可将软件版本标注为 beta版。
RC :该版本已经相当成熟了,基本上不存在导致错误的Bug,与即将发行的正式版本相差无几。
Release:该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式的版本,是最终交付用户使用的一个版本。
该版本有时也称标准版。
3. 3.版本号修改规则(1)主版本号:当功能模块有较大的变动,比如增加模块或是整体架构发生变化。
此版本号由项目决定是否修改。
(2)次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或增强。
此版本号由项目决定是否修改。
(3)修订版本号:一般是Bug 的修复或是一些小的变动或是一些功能的扩充,要经常发布修订版,修复一个严重 Bug 即可发布一个修订版。
此版本号由项目经理决定是否修改。
常见的软件版本编号及命名
常见的软件版本编号及命名1、RC,GARC:就是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版。
软件产品命名规范
文件编号:XXX公司质量管理体系文件软件产品命名规范Version B/0XXX公司修改记录1.目的为了确保公司各个软件产品及程序的正确性、统一性,确保各方面内容受到保护和修改控制,确保各项工作顺利进行,特此制定本公司软件产品命名规范,凡本公司设计开发的软件产品及程序均应符合本规范。
2.适用范围本规定适用于公司所有软件产品和每一个可独立维护并受控的程序。
3.名词定义程序:程序是一系列按照特定顺序组织的计算机数据和指令的集合。
一般指源码的编译成果,程序的类型包括dll、exe、ocx、jar、war等。
软件产品:软件产品是程序设计的最终结果,是最终向用户发布的软件。
它可以是一个特定的程序,也可以是一组功能联系紧密,可以互相协作的程序的集合。
此外软件产品还应包括与这些程序相关的文档。
4.软件产品标识软件产品的标识由软件产品名称和软件产品的版本两部分参数组成。
4.1软件产品名称软件产品一般都有中文名称、英文名称及简称三种方式的标识。
公司所有软件产品在立项开发时,软件产品名称按统一标准命名,标准说明如下:4.1.1软件产品的中文名称软件产品的中文名称要求能够体现产品内容和产品属性。
4.1.2软件产品英文名称软件产品的英文名称由三部分组成:公司的标识(EHL)、产品标志(目前一般用Smart、ATMS等)、中文名称的英文全称。
除英文缩写组合外,英文单词都采用首字母或关键字母大写的方法。
例如:EHL Smart Data Synchronizes System4.1.3软件产品的简称软件产品的简称也是由三部分组成:公司的标识、产品标志、英文名称的缩写(一般为各单词首字母组合)。
例如:EHL Smart DSS4.2软件产品版本软件产品的版本直接体现在版本号的命名上,命名格式有两种:主版本号. 子版本号或主版本号. 子版本号. 变更版本号. 修正版本号当软件产品初版时,变更版本号和修正版本号都为0,可以忽略不计,所以采用第一种方式,只标识主版本号和子版本号;主版本号和子版本号的修改标志这软件产品的升级开发,须提交立项申请,由立项评审委员会决定。
产品软件及用户指导类手册版本编号规则
产品软件及用户指导类手册版本编号规则在软件开发和用户指导文档编写中,版本编号的规则起到了重要的作用。
准确的版本编号可以方便开发团队和用户及时了解软件的更新和改进内容。
本文将介绍一种常见的产品软件及用户指导类手册版本编号规则,以帮助开发团队统一版本管理和用户方便使用。
一、版本编号的概念和重要性版本编号是指为标识软件或文档的不同版本而进行的编码命名。
每个版本都会有特定的改进、修复或新增功能,因此为每个版本分配唯一的编号是必要的。
版本编号的正确定义和使用可以帮助团队成员和用户准确地识别和使用最新的软件版本。
二、版本编号的组成方式在本规则中,我们采用主版本号(Major Version Number)、次版本号(Minor Version Number)和修订号(Revision Number)的组合方式,形成一个标识版本的编号。
具体如下所示:主版本号.次版本号.修订号1. 主版本号(Major Version Number):指的是软件或用户指导文档的重大更新或重大改变。
当软件或文档发生较大规模的改进时,主版本号应进行加一操作。
2. 次版本号(Minor Version Number):指软件或用户指导文档的较小更新或改进。
当软件或文档发生较小范围的改进时,次版本号应加一。
3. 修订号(Revision Number):指对软件或用户指导文档进行的错误修复、调整或其他较小的修改操作。
每次修订后,修订号应加一。
三、版本编号的使用示例以一个虚拟的软件 "ABC软件" 为例,我们采用上述版本编号规则进行标识。
初始版本为:1.0.01. 当 ABC 软件进行了全面升级和重大改进后,改动较大,此时主版本号加一:2.0.02. 紧接着进行了一些较小的功能调整和修订,次版本号加一:2.1.03. 后续进行了一些错误修复和细微调整,修订号加一:2.1.14. 又进行了一些功能优化和细节修正,修订号加一:2.1.2在用户指导文档方面,找到与软件版本相对应的用户指导类手册版本号,以便用户能够获取正确的文档。
软件开发版本控制规范详解
软件开发版本控制规范详解在软件开发过程中,版本控制是非常重要的一环。
它能够帮助开发团队有效地协同工作、管理代码及项目的变更。
本文将详细介绍软件开发版本控制的规范,包括命名规则、分支管理、代码审核以及发布流程等内容。
一、命名规则在版本控制中,合理的命名规则能够使开发人员快速识别和定位不同的版本。
下面是一些常用的命名规则示例:1. 主版本号(Major Version).次版本号(Minor Version).修订号(Revision Number):例如1.0.0。
2. 年份.月份.修订号:例如2023.09.01。
3. 使用语义化版本(Semantic Versioning):例如v1.0.0-alpha.1。
团队可根据实际需要选择适合自己的命名规则,但需要确保团队成员之间的统一和沟通畅通。
二、分支管理有效的分支管理可以帮助团队并行开发不同的功能和修复bug,同时减少代码冲突的发生。
下面是一些常用的分支管理策略:1. 主分支(Master):用来保存稳定的正式版本,只能从其他分支合并,不能直接在该分支上修改代码。
2. 开发分支(Develop):用来集成各个开发人员的代码,是日常开发工作的主要分支。
3. 功能分支(Feature):用来开发新功能的分支,从开发分支上创建,开发完成后合并回开发分支。
4. 修复分支(Bugfix):用来修复线上问题的分支,从主分支上创建,修复完成后合并回主分支和开发分支。
5. 发布分支(Release):用来准备发布正式版本的分支,从开发分支上创建,进行代码审核、打包、测试等工作,完成后合并回主分支。
团队可根据具体项目和团队规模选择适合的分支管理策略,并在团队中建立相应的分支管理流程。
三、代码审核代码审核是保证软件质量的重要环节,它能够发现和纠正潜在的问题,提升代码的可维护性。
下面是一些常用的代码审核规范:1. 代码静态分析工具:使用静态代码分析工具,如Lint、SonarQube等,对代码进行自动检查,并根据检查结果进行修改。
软件版本号规范
软件版本号规范1. 软件版本阶段说明o Base版: 此版本表⽰该软件仅仅是⼀个假页⾯链接,通常包括所有的功能和页⾯布局,但是页⾯中的功能都没有做完整的实现,只是做为整体⽹站的⼀个基础架构。
o Alpha版: 此版本表⽰该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,⼀般⽽⾔,该版本软件的Bug较多,需要继续修改。
o Beta版: 该版本相对于α版已有了很⼤的改进,消除了严重的错误,但还是存在着⼀些缺陷,需要经过多次测试来进⼀步消除,此版本主要的修改对像是软件的UI。
o RC版: 该版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发⾏的正式版相差⽆⼏。
o Release版: 该版本意味“最终版本”,在前⾯版本的⼀系列测试版之后,终归会有⼀个正式版本,是最终交付⽤户使⽤的⼀个版本。
该版本有时也称为标准版。
⼀般情况下,Release不会以单词形式出现在软件封⾯上,取⽽代之的是符号(R)。
2. 版本命名规范 软件版本号由四部分组成,第⼀个1为主版本号,第⼆个1为⼦版本号,第三个1为阶段版本号,第四部分为⽇期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。
例如:1.1.1.051021_beta。
版本号定修改规则:o 主版本号(1):当功能模块有较⼤的变动,⽐如增加多个模块或者整体架构发⽣变化。
此版本号由项⽬决定是否修改。
o ⼦版本号(1):当功能有⼀定的增加或变化,⽐如增加了对权限控制、增加⾃定义视图等功能。
此版本号由项⽬决定是否修改。
o 阶段版本号(1):⼀般是 Bug 修复或是⼀些⼩的变动,要经常发布修订版,时间间隔不限,修复⼀个严重的bug即可发布⼀个修订版。
此版本号由项⽬经理决定是否修改。
o ⽇期版本号(051021):⽤于记录修改项⽬的当前⽇期,每天对项⽬的修改都需要更改⽇期版本号。
此版本号由开发⼈员决定是否修改。
4软件产品命名规范
文件编号:Q/EHL-CX08-ZY02-2008北京易华录信息技术股份有限公司质量管理体系文件软件产品命名规范Version B/0编写:樊平审核:李艳东批准:李艳东实施日期:2009-2-1受控状态:受控发放编号:北京易华录信息技术股份有限公司二零零九年修改记录1.目的为了确保公司各个软件产品及程序的正确性、统一性,确保各方面内容受到保护和修改控制,确保各项工作顺利进行,特此制定本公司软件产品命名规范,凡本公司设计开发的软件产品及程序均应符合本规范。
2.适用范围本规定适用于公司所有软件产品和每一个可独立维护并受控的程序。
3.名词定义程序:程序是一系列按照特定顺序组织的计算机数据和指令的集合。
一般指源码的编译成果,程序的类型包括dll、exe、ocx、jar、war等。
软件产品:软件产品是程序设计的最终结果,是最终向用户发布的软件。
它可以是一个特定的程序,也可以是一组功能联系紧密,可以互相协作的程序的集合。
此外软件产品还应包括与这些程序相关的文档。
4.软件产品标识软件产品的标识由软件产品名称和软件产品的版本两部分参数组成。
4.1软件产品名称软件产品一般都有中文名称、英文名称及简称三种方式的标识。
公司所有软件产品在立项开发时,软件产品名称按统一标准命名,标准说明如下:4.1.1软件产品的中文名称软件产品的中文名称要求能够体现产品内容和产品属性。
4.1.2软件产品英文名称软件产品的英文名称由三部分组成:公司的标识(EHL)、产品标志(目前一般用Smart、ATMS等)、中文名称的英文全称。
除英文缩写组合外,英文单词都采用首字母或关键字母大写的方法。
例如:EHL Smart Data Synchronizes System4.1.3软件产品的简称软件产品的简称也是由三部分组成:公司的标识、产品标志、英文名称的缩写(一般为各单词首字母组合)。
例如:EHL Smart DSS4.2软件产品版本软件产品的版本直接体现在版本号的命名上,命名格式有两种:主版本号 . 子版本号或主版本号 . 子版本号 . 变更版本号 . 修正版本号当软件产品初版时,变更版本号和修正版本号都为0,可以忽略不计,所以采用第一种方式,只标识主版本号和子版本号;主版本号和子版本号的修改标志这软件产品的升级开发,须提交立项申请,由立项评审委员会决定。
常见的软件版本编号及命名
常见的软件版本编号及命名1、RC,GARC:就是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版。
软件版本管理规范
文件制修订记录1.0目的规范软件产品版本升级流程,规范管理版本号,加强不同版本软件保存的可靠性。
2.0范围研发结束进行测试或投入应用的独立软件产品和已销售产品中的独立软件产品的升级或变更管理。
3.0职责3.1 IT 部负责管理软件版本号并在软件升级结束后向生产部提供新版本的软件系统。
3.2 IT 部项目负责人及软件工程师负责对软件系统进行升级并记录升级信息。
3.3软件工程师在完成软件安装后应填写《客户版本信息清单》,提交IT 部进行归档。
4.0程序4.1 软件版本命名:4.1.1软件版本号由四部分组成: 4.1.1.1第一部分主版本号; 4.1.1.2第二部分子版本号; 4.1.1.3第三部分阶段版本号;4.1.1.4第四部分日期加希腊字母版本号;例如:主版本号4.2 版本变更4.2.1对于重大类软件更新,项目负责人组织技术部、质量部进行会议进行评审。
4.2.2对于增强类软件更新,项目负责人组织技术部进行会议进行评审。
4.2.3对于纠正类软件更新,项目负责人直接分配此次更新的工作任务。
4.2.4所有变更过程参照《软件更新控制程序》要求执行。
4.3 软件版本输出4.3.1生产部软件版本管理员必须是外界获取应用程序的唯一出口。
4.3.2生产部版本管理员必须对交付产品中的软件信息做出详细记录并对该销售产品的升级及变更情况做出记录。
4.3.3IT部对软件变更升级后必须再次向版本管理员提供升级后的软件版本。
4.4软件版本的储存4.4.1在产品配置库为每个项目组分配产品输出存储区域。
并为相应的项目负责人分配写读权限。
生产部版本管理员分配只读权限。
4.4.2软件项目负责人将源代码及应用程序上传到软件服务器的配置库并刻录光盘存档。
5.0相关文件《软件更新控制程序》6.0相关记录《培训记录》ISO13485-2016/ISO9001/IATF16949文件范例客户培训签到表项目名称:_________________________课程名称:_________________________ 日期: ______________。
软件版本控制规范
软件版本控制规范1. 引言随着软件开发的不断发展,软件版本控制变得越来越重要。
软件版本控制规范旨在确保软件开发团队能够有效管理软件版本的变化,提高团队的生产力和协作效率。
本文将介绍一套软件版本控制规范,旨在帮助开发团队更好地进行版本控制管理。
2. 版本命名规则为了便于管理和识别,每个软件版本应该有一个唯一的标识符。
以下是一些建议的版本命名规则:- 主版本号:表示较大的功能改动或架构调整,当进行不兼容的升级时,应递增主版本号。
- 次版本号:表示重要的功能增加或接口变化,当增加新功能时,应递增次版本号。
- 修订号:表示小的变动或缺陷修复,当进行缺陷修复或较小的改进时,应递增修订号。
3. 版本库管理为了有效地进行版本控制,建议使用版本控制系统进行代码管理和版本库管理。
常见的版本控制系统包括Git和SVN等。
以下是一些版本库管理的最佳实践:- 创建主干(master)分支:主干分支用于存放稳定版本的代码,并且只允许经过严格测试和验证的代码合并到主干分支。
- 创建开发分支:开发分支用于开发新功能或进行较大的改动,开发人员在该分支上进行开发和测试。
- 创建特性分支:特性分支用于开发某个特定功能,每个特性分支都应该有明确的目标和范围,并且及时合并到开发分支或主干分支。
- 创建修复分支:修复分支用于修复已发布版本的缺陷,修复后的代码应及时合并到对应的分支上。
4. 提交规范为了确保代码的质量和可追溯性,提交代码时应遵循以下规范:- 提交信息:每次提交都应该有明确的提交信息,描述本次提交的目的和内容。
- 提交频率:建议经常提交代码,以保持版本库的及时更新和备份。
- 提交前测试:在提交代码之前,应进行必要的测试和验证,确保代码的正确性和可靠性。
- 代码审查:对于重要的代码改动,建议进行代码审查,以确保代码质量和一致性。
5. 版本发布版本发布是软件开发过程中的重要环节,以下是一些版本发布的最佳实践:- 版本号管理:每个发布的软件版本都应有唯一的版本号,并且按照规定的版本命名规则进行命名。
软件版本管理制度
软件版本管理制度一、版本控制策略1.1 分支策略:采用主干分支和开发分支的模式进行版本管理。
主干分支用于发布稳定版本,开发分支用于开发新功能和解决Bug。
1.2 版本补丁策略:对于已发布的版本,如果出现Bug或需要进行紧急修复,应及时创建相应的版本补丁,并在修复完成后进行发布。
1.3版本合并策略:在进行版本合并时,应采用先合并主干分支到开发分支,再将开发分支合并回主干分支的方式,以确保版本的一致性和稳定性。
二、版本标识2.1 版本号命名规则:采用主版本号、次版本号和修订号的方式进行版本号命名,例如1.0.1、其中,主版本号表示做大的功能更新或重大改进,次版本号表示较小的功能更新或优化,修订号表示Bug修复和小的改进。
2.2发布标识:在软件版本发布时,应标明发布日期和版本号,并将相应的发布记录和变更记录保存在版本库中。
三、版本发布流程3.1需求评审:根据需求文档进行评审,确保需求明确、合理,并与开发、测试等相关部门进行沟通,明确开发计划和进度。
3.2开发阶段:根据需求进行软件开发,开发完成后进行自测,确保主要功能的正确性和稳定性。
3.3内部测试:将开发完成的软件版本交付给测试人员进行测试,包括功能测试、性能测试、稳定性测试等,发现并修复问题。
3.4外部测试:将经过内部测试的版本交付给外部用户进行测试,并收集用户反馈,发现并修复问题。
3.6 版本维护:在软件版本发布后,根据用户反馈和需求变更,及时修复Bug和添加新功能,并按照版本控制策略进行版本合并和版本补丁发布。
四、版本库管理4.1版本库的建立:建立软件版本库,用于存储软件的历史版本和变更记录。
4.2版本库权限管理:对版本库进行权限管理,确保只有授权人员才能进行版本控制操作,防止误操作和非授权访问。
4.3版本库备份和恢复:定期对版本库进行备份,并确保备份数据的完整性和可恢复性。
4.4版本库的访问与检索:通过版本控制工具,实现对版本库的访问与检索,方便查找和回溯历史版本。
软件产品版本命名规范
软件产品版本命名规范软件版本阶段说明及命名规范* Base版: 此版本表⽰该软件仅仅是⼀个假页⾯链接,通常包括所有的功能和页⾯布局,但是页⾯中的功能都没有做完整的实现,只是做为整体⽹站的⼀个基础架构。
* Alpha版: 此版本表⽰该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,⼀般⽽⾔,该版本软件的Bug较多,需要继续修改。
* Beta版: 该版本相对于α版已有了很⼤的改进,消除了严重的错误,但还是存在着⼀些缺陷,需要经过多次测试来进⼀步消除,此版本主要的修改对像是软件的UI。
* RC版: 该版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发⾏的正式版相差⽆⼏。
* Release版: 该版本意味“最终版本”,在前⾯版本的⼀系列测试版之后,终归会有⼀个正式版本,是最终交付⽤户使⽤的⼀个版本。
该版本有时也称为标准版。
⼀般情况下,Release不会以单词形式出现在软件封⾯上,取⽽代之的是符号(R)。
2. 版本命名规范 软件版本号由四部分组成,第⼀个1为主版本号,第⼆个1为⼦版本号,第三个1为阶段版本号,第四部分为⽇期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。
例如:1.1.1.051021_beta。
# 版本号定修改规则:* 主版本号(1):当功能模块有较⼤的变动,⽐如增加多个模块或者整体架构发⽣变化。
此版本号由项⽬决定是否修改。
* ⼦版本号(1):当功能有⼀定的增加或变化,⽐如增加了对权限控制、增加⾃定义视图等功能。
此版本号由项⽬决定是否修改。
* 阶段版本号(1):⼀般是 Bug 修复或是⼀些⼩的变动,要经常发布修订版,时间间隔不限,修复⼀个严重的bug即可发布⼀个修订版。
此版本号由项⽬经理决定是否修改。
* ⽇期版本号(051021):⽤于记录修改项⽬的当前⽇期,每天对项⽬的修改都需要更改⽇期版本号。
此版本号由开发⼈员决定是否修改。
版本号命名规范
文件编号:上海摩力游数字娱乐有限公司质量管理体系文件软件产品命名规范Version B/0编写:朱守炜审核:郭园园批准:实施日期:受控状态:发放编号:部门会签人/日期部门会签人/日期文件会签上海摩力游数字娱乐有限公司2011年修改记录日期版本说明修改人2011/3/15 1.0.0 软件产品版本规范编写朱守炜1.目的为了确保公司各个软件产品及程序的正确性、统一性,确保各方面内容受到保护和修改控制,确保各项工作顺利进行,特此制定本公司软件产品命名规范,凡本公司设计开发的软件产品及程序均应符合本规范。
2.适用范围本规定适用于公司所有软件产品和每一个可独立维护并受控的程序。
3.名词定义程序:程序是一系列按照特定顺序组织的计算机数据和指令的集合。
一般指源码的编译成果,程序的类型包括dll、exe、ocx、jar、war等。
软件产品:软件产品是程序设计的最终结果,是最终向用户发布的软件。
它可以是一个特定的程序,也可以是一组功能联系紧密,可以互相协作的程序的集合。
此外软件产品还应包括与这些程序相关的文档。
4.软件产品标识软件产品的标识由软件产品名称和软件产品的版本两部分参数组成。
4.1软件产品名称软件产品一般都有中文名称、英文名称及简称三种方式的标识。
公司所有软件产品在立项开发时,软件产品名称按统一标准命名,标准说明如下:4.1.1软件产品的中文名称软件产品的中文名称要求能够体现产品内容和产品属性。
4.1.2软件产品英文名称软件产品的英文名称由三部分组成:公司的标识、产品标志中文名称的英文全称。
除英文缩写组合外,英文单词都采用首字母或关键字母大写的方法。
例如:Moliyo King Of Sea4.1.3软件产品的简称软件产品的简称也是由三部分组成:英文名称的缩写(一般为各单词首字母组合)。
例如:C2 KOP KOS4.2软件产品版本软件产品的版本直接体现在版本号的命名上,命名格式为产品名缩写. 地区名缩写. 主版本号 . 特征版本号 . 修正版本号【. 送测版本号 . 构建次数】当软件产品初版时,特征版本号和修正版本号都为0,可以忽略不计。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件产品版本号命名规范
1、目的
规范软件产品版本号,避免软件测试、发布时软件各模块版本不兼容问题。
2、范围
C3M平台软件及绿色行动管理平台。
3、命名规范
软件产品版本号命名规范参考 .Net Framework风格的版本号命名格式,以:主版本号.次版本号.内部版本号.修订号四位表示。
软件初版时,版本号为:1.0.0.0。
主版本号:标识软件架构、设计思想,主版本号不同的程序集不可互换,即使具有相同名称也不可互换。
软件架构、设计思想改变或大量重写,主版本号加1。
主版本号改变,不支持向后兼容性,次版本号、内部版本号及修订号复位为0。
次版本号:当在原有基础上增加了部分功能,涉及数据库的改动,次版本号加1,内部版本号及修订号复位为0。
内部版本号:当软件各模块间接口变更时,内部版本号加1,修订号复位为0。
只要有某个或某几个模块的接口发生变动,所有模块的内部版本号统一增加1。
修订号:名称、主版本号、次版本号、内部版本号都相同,但修
订号不相同的程序集可以完全互换。
以软件编译日期(月日)4位数字作为修订号,如10月5号,则为1005。
当天发布的多次软件,用后编译的软件程序完全替换前边编译的软件程序。
主版本号、次版号及内部版本号,其中任何一个如果需要变更,需要向软件负责人申请,由软件负责人确定。
软件负责人将统一修改软件产品版本号,并通知所有相关开发人员。
开发人员每次的改动必须写开发日志,注明改动了哪些东西,修正了哪些BUG,是否对其它模块有影响,是否对数据库有改动。
软件产品所需要的主版本号、次版本号、内部版本号,出现任何一个变更,软件产品需要整体升级。
4、软件模块版本号
软件各模块需要独立的主版本号、次版本号、内部版本号,其中对公共模块或公共组件的版本号,为完全独立的版本号,与软件产品版本号的主版本号,次版本号,内部版本号无关。
对业务模块的版本号,其主版本号与软件产品的版本号一致,次版本号,内部版本号为独立版本号。
但要求与软件产品的版本号的编码格式一致。
对多个业务模块依赖的公共部分或相关改动,需要同步进行升级关联的业务模块相关版本号。
5、数据库脚本
以现有数据库对象(表,视图,存储过程,触发器,系列,包等)为基础,整理一份空数据库(基本配置数据保留)作为原始数据库,并生成原始脚本,与软件初始版本配套使用。
数据库每次变更必须写SQL脚本,并注明是在哪个版本中生成的,以便数据库的升级。
脚本文件名称要写明脚本的创建时间、操作用户、操作内容,如:20090909_GXX13_创建存储过程P_Alarm。
脚本内容要写注释,详细说明脚本作用,对应软件模块版本等信息。
如果多个脚本有先后执行顺序要求,要在名称中写明顺序号。
当涉及对数据库结构发生变动时,修改软件模块版本号次版本号;只对数据做改动,程序不需要修改时,修改软件模块版本号的修订号。
6、配置库版本与软件产品版本关系
在软件每次发布时维护配置库SVN代码版本,软件模块版本号,数据库之间的关系。
需要记录软件产品与代码版本对应关系,包括SVN代码版本、数据库、及软件各模块代码。
此表的作用在于明确产品版本与SVN代码版本号的对应关系,便于配置管理,同时指定数据库脚本,配套使用,共同发布管理。
其中软件模块版本号,便于分析,解决问题,为软件内部使用。
公共基础平台 V2.0.0
基站巡检管理系统-WEB V1.3.2
基站巡检管理系统-WM V1.3.2
基站巡检管理系统-WinCE V1.3.2
基站巡检管理系统-Android V1.0.0
油机调度系统-WEB V2.0.0
油机调度系统-WM V2.0.0
机房综合进出管理系统 V1.0.0
渠道巡检管理系统-WEB V2.0.0
渠道巡检管理系统-WM V2.0.0
集团客户运营支撑管理系统-WEB V1.0.0集团客户运营支撑管理系统-WM V1.0.0
集团客户拜访管理系统-WEB V3.0.0
集团客户拜访管理系统-Symbian V3.0.0
租赁通-WEB V1.7.0
租赁通-WM V1.7.0
东莞出租屋PDA巡检系统-WEB V3.0.0
东莞出租屋PDA巡检系统-WM V3.0.0
东莞出租屋PDA巡检系统-Android V3.0.0 .。