版本号命名规范
版本管理规范

版本管理规范一、引言版本管理是软件开辟过程中非常重要的一环,它能够有效地管理软件的版本、变更和发布,确保团队成员之间的协作顺畅,同时也能够提高软件开辟的质量和效率。
本文将介绍版本管理规范的制定目的、适合范围和基本原则,以及具体的版本管理流程和规范要求。
二、目的版本管理规范的目的是为了规范团队成员在软件开辟过程中的版本管理行为,确保软件开辟过程的可控性和可追溯性,提高团队协作效率,减少版本冲突和错误,保证软件的稳定性和可靠性。
三、适合范围本版本管理规范适合于所有软件开辟项目,包括但不限于需求分析、设计、编码、测试和发布等阶段。
四、基本原则1. 版本命名规范:版本号应采用主版本号.次版本号.修订号的格式,例如1.0.0,其中主版本号表示重大功能更新或者架构变更,次版本号表示功能增加或者改进,修订号表示错误修复或者小的改动。
2. 版本控制工具:团队成员应使用统一的版本控制工具进行代码管理,常用的版本控制工具有Git、SVN等。
3. 分支管理策略:根据项目的需要,合理规划分支管理策略,例如主分支用于发布稳定版本,开辟分支用于新功能的开辟,修复分支用于错误修复等。
定性,同时记录版本发布的相关信息,如发布日期、发布内容等。
5. 变更管理:对于每一次代码变更,都应记录变更的内容、原因和责任人,并及时通知相关人员。
五、版本管理流程1. 创建新的版本:在开始新的开辟任务之前,团队成员应基于主分支创建新的开辟分支,并根据任务的名称或者编号进行命名。
2. 开辟和测试:团队成员在各自的开辟分支上进行开辟和测试工作,确保代码的质量和功能的完整性。
3. 合并和冲突解决:当开辟任务完成后,团队成员将代码合并到主分支,并解决可能浮现的冲突。
4. 版本发布:在主分支上完成代码合并和冲突解决后,进行版本发布前的测试和审核工作,确保版本的质量和稳定性。
5. 变更管理:对于每一次代码变更,团队成员应及时记录变更的内容、原因和责任人,并通知相关人员。
产品版本管理规范

产品版本管理规范产品版本管理规范一、引言随着企业业务的快速发展,产品线不断拓展,版本管理的需求日益凸显。
为了提高产品版本的稳定性、可维护性及可追溯性,制定一套科学合理的版本管理规范至关重要。
本规范旨在明确版本管理的原则、流程、工具、发布策略和质量控制方法,为产品研发团队提供指导。
二、版本管理原则1.版本命名规范:采用“主版本号.次版本号.修订号”的格式,例如:1.2.3。
每个版本号均为整数,主版本号和次版本号均为正数,修订号可以为0或负数。
2.版本所包含内容:每个版本应明确标识所包含的功能、修复的问题、新增的功能等内容,以便追溯。
3.版本发布流程:制定严格的版本发布流程,包括需求分析、设计、开发、测试、上线等环节,确保版本的稳定性和质量。
三、版本管理流程1.需求分析:对市场需求、用户反馈等进行梳理,形成版本需求列表。
2.设计:根据需求列表,进行版本设计,包括功能设计、界面设计、架构设计等。
3.开发:按照设计文档,进行编码开发,同时进行单元测试和代码审查。
4.测试:进行集成测试、系统测试和验收测试,确保版本的质量和稳定性。
5.上线:经过测试验证后,将版本发布至生产环境,并进行持续跟踪和监控。
四、版本管理工具1.Git:使用Git作为版本控制工具,进行代码的版本管理。
2.Jira:使用Jira作为项目管理工具,跟踪和管理版本的研发进度。
3.SonarQube:使用SonarQube进行代码质量检查和静态代码分析。
4.Jenkins:使用Jenkins进行自动化构建和持续集成。
五、版本发布策略1.按需发布:根据市场需求和用户反馈,针对特定的用户群体或产品线进行版本发布。
2.同步发布:针对多个平台或产品线,进行同步的版本发布,以确保用户体验的一致性。
3.排队等候:按照优先级和重要程度,排队进行版本的发布,确保关键问题得到优先解决。
六、版本质量控制1.需求评审:对每个版本的需求进行严格评审,确保需求的合理性和可行性。
软件版本命名规范

产品经理、项目经理、开发工程师、配置工程师、配置管理员、产品/项目管理者。
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概述
本规范定义软件版本的命名原则,编号定义,不同状态下版本遵循的命名要求等,包括过程版本、商用发布版本、试用版本、补丁版本、定制版本等。
版本控制比较普遍的 3 种命名格式

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

Z的升级包含小功能变化或局部性能小改进;小功能变化一般是指在现有的子系统、模块和业务单元下增加或修改一个或几个功能,不会引起系统导航区的大变化,也不会引起系统菜单区的内容的大变化;局部性能小改进通常指为改善系统的部分功能的性能而做的系统局部组件升级或性能优化。
维护版本Pmm的升级主要是包含一个或多个对原有功能的紧急变更或对当前版本的缺陷修复;维护版本的升级通常不会新增功能,也不会引起系统菜单区或者导航区的内容的变化(仅文字的变化除外)。
重要变更
B中版本(改动较大的多项功能改版)
Y的升级包含一组中小功能的变化或者局部性能较大改进;中小功能变化一般是指在现有的模块下增加或较大修改一个或多个单元,通常会引起系统导航区的内容变化,和系统菜单区的内容较大变化;局部性能较大改进通常指为改善系统的局部性能而做的系统局部架构升级或性能优化。
小变更、bug修复
版本序列
标签
主版本号A
从版本号B
次版本号C
取 值
V
1-9
0-30
01-99
说明
versionБайду номын сангаас
A类需求变更
B类需求变更
C类需求变更、BUG修复
加值规则
详看产品变更等级表
详看产品变更等级表
详看产品变更等级表
发布规则
版本号只增不减,初始版本号为:V1.0或V1.0.0,历史版本从V3.0.0开始。内部版本从初始版本开始变化,每一次变化均是在前一个版本的基础上进行的变更。
产品功能开发需求文档命名规范
一、文档命名规则
产品功能策划文档的命名规范,主要是通过产品功能名称、策划案攥写的年份、版本序列号的组合来命名。如:网盘_2012V3.4.5;
软件版本号规范

软件版本号规范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):⽤于记录修改项⽬的当前⽇期,每天对项⽬的修改都需要更改⽇期版本号。
此版本号由开发⼈员决定是否修改。
软件项目版本号的命名规则及格式

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

通用尾标命名规范要求有哪些通用尾标命名规范是指在文件名或者目录名的末尾添加一些特定的标识符,以便更好地区分不同类型的文件或者目录。
以下是一些常见的通用尾标命名规范要求:1. 类型标识:常见的类型标识包括文件类型、目录类型、备份类型等。
例如,常见的文件类型标识有:.txt(文本文件)、.docx(Word文档)、.xlsx(Excel表格)等。
2. 版本号:当文件或者目录存在多个版本时,可以通过添加版本号进行区分。
版本号一般使用数字或字母表示,例如v1、v2、v3等。
3. 更新时间:在文件或者目录发生更新时,可以在末尾添加更新的时间。
时间一般使用YYYYMMDD或者YYYYMMDDHHMMSS等格式表示,例如20211231、20211231120000等。
4. 创建者标识:在多人协作的情况下,可以在文件或者目录的末尾添加创建者的姓名或者代码。
例如,John Smith创建的文件可以命名为file_JohnSmith。
5. 关键词标识:根据文件或者目录的内容,可以在末尾添加关键词以便更好地描述。
例如,图片文件可以添加.png或者.jpg 等后缀名,表示图片类型。
6. 地点标识:如果涉及到不同地点的文件或者目录,可以在末尾添加地点标识以区分。
例如,不同分部门的文件可以添加地点代码,如A部门的文件可以命名为file_A。
7. 状态标识:对于一些特殊状态的文件或者目录,可以在末尾添加特定的状态标识。
例如,已归档的文件可以添加_archived 标识。
8. 函数标识:对于某些具有特定功能的文件或者目录,可以在末尾添加函数标识。
例如,带有备份功能的目录可以添加_backup标识。
需要注意的是,通用尾标命名规范可以根据具体情况进行调整和扩展,以满足实际需求。
同时,为了保持文件和目录的可读性和可维护性,应尽量遵守命名规范并保持一致性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
版本控制比较普遍的 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.项目初版本时,版本号可以为 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 -- 多语言版软件版本号总结:V(Version):即版本,通常用数字表示版本号。
(如:EVEREST Ultimate v4.20.1188 Beta )Build:用数字或日期标示版本号的一种方式。