软件项目版本号的命名规则及格式
版本命名规范
![版本命名规范](https://img.taocdn.com/s3/m/7a14c4722a160b4e767f5acfa1c7aa00b52a9dda.png)
版本命名规范版本命名规范是指在软件开发过程中,为不同版本的软件定义一个规范的命名方式,以便于统一管理和识别各个版本。
版本命名规范通常包括以下几个方面的考虑。
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. 向后兼容性:在更新版本时,尽量保持向后兼容。
如果新版本不兼容旧版本的接口或数据格式,可以将主版本号进行更新。
总的来说,版本命名规范应该便于管理和识别不同的版本,并充分表达版本之间的差异和进展。
版本管理规范
![版本管理规范](https://img.taocdn.com/s3/m/a74cc05ea200a6c30c22590102020740be1ecd36.png)
版本管理规范一、引言版本管理是软件开辟过程中非常重要的一环,它能够有效地管理软件的版本、变更和发布,确保团队成员之间的协作顺畅,同时也能够提高软件开辟的质量和效率。
本文将介绍版本管理规范的制定目的、适合范围和基本原则,以及具体的版本管理流程和规范要求。
二、目的版本管理规范的目的是为了规范团队成员在软件开辟过程中的版本管理行为,确保软件开辟过程的可控性和可追溯性,提高团队协作效率,减少版本冲突和错误,保证软件的稳定性和可靠性。
三、适合范围本版本管理规范适合于所有软件开辟项目,包括但不限于需求分析、设计、编码、测试和发布等阶段。
四、基本原则1. 版本命名规范:版本号应采用主版本号.次版本号.修订号的格式,例如1.0.0,其中主版本号表示重大功能更新或者架构变更,次版本号表示功能增加或者改进,修订号表示错误修复或者小的改动。
2. 版本控制工具:团队成员应使用统一的版本控制工具进行代码管理,常用的版本控制工具有Git、SVN等。
3. 分支管理策略:根据项目的需要,合理规划分支管理策略,例如主分支用于发布稳定版本,开辟分支用于新功能的开辟,修复分支用于错误修复等。
定性,同时记录版本发布的相关信息,如发布日期、发布内容等。
5. 变更管理:对于每一次代码变更,都应记录变更的内容、原因和责任人,并及时通知相关人员。
五、版本管理流程1. 创建新的版本:在开始新的开辟任务之前,团队成员应基于主分支创建新的开辟分支,并根据任务的名称或者编号进行命名。
2. 开辟和测试:团队成员在各自的开辟分支上进行开辟和测试工作,确保代码的质量和功能的完整性。
3. 合并和冲突解决:当开辟任务完成后,团队成员将代码合并到主分支,并解决可能浮现的冲突。
4. 版本发布:在主分支上完成代码合并和冲突解决后,进行版本发布前的测试和审核工作,确保版本的质量和稳定性。
5. 变更管理:对于每一次代码变更,团队成员应及时记录变更的内容、原因和责任人,并通知相关人员。
软件版本命名规范
![软件版本命名规范](https://img.taocdn.com/s3/m/7cabc7abc281e53a5902ffb4.png)
产品经理、项目经理、开发工程师、配置工程师、配置管理员、产品/项目管理者。
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概述
本规范定义软件版本的命名原则,编号定义,不同状态下版本遵循的命名要求等,包括过程版本、商用发布版本、试用版本、补丁版本、定制版本等。
软件版本号命名规范
![软件版本号命名规范](https://img.taocdn.com/s3/m/7246d83ebd64783e09122bfe.png)
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 即可发布一个修订版。
此版本号由项目经理决定是否修改。
版本号命名规则
![版本号命名规则](https://img.taocdn.com/s3/m/59e0bc37453610661ed9f4d9.png)
版本命名规范1. 版本命名规范软件版本号由四部分组成:第一个1为主版本号第二个1为子版本号第三个1为阶段版本号第四部分为日期版本号加希腊字母版本号希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。
例如:1.0.0.081015_ release常规:完全的版本号定义,分三项::<主版本号>.<次版本号>.<修订版本号>,如 1.0.02. 版本号定修改规则主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。
此版本号由项目决定是否修改。
阶段版本号(1):一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。
此版本号由项目经理决定是否修改。
日期版本号(051021):用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。
此版本号由开发人员决定是否修改。
希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。
此版本号由项目决定是否修改。
3. 文件命名规范文件名称由四部分组成:第一部分为项目名称,第二部分为文件的描述,第三部分为当前软件的版本号,第四部分为文件阶段标识加文件后缀,例如:rongliaoRCS 1.0.0.081015_release.apk,此文件为项目外包平台的测试报告文档,版本号为:1.0.0.081015_ release。
软件开发版本控制规范详解
![软件开发版本控制规范详解](https://img.taocdn.com/s3/m/3b2048b7f605cc1755270722192e453611665b68.png)
软件开发版本控制规范详解在软件开发过程中,版本控制是非常重要的一环。
它能够帮助开发团队有效地协同工作、管理代码及项目的变更。
本文将详细介绍软件开发版本控制的规范,包括命名规则、分支管理、代码审核以及发布流程等内容。
一、命名规则在版本控制中,合理的命名规则能够使开发人员快速识别和定位不同的版本。
下面是一些常用的命名规则示例: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等,对代码进行自动检查,并根据检查结果进行修改。
软件版本管理规范
![软件版本管理规范](https://img.taocdn.com/s3/m/9e1805531fb91a37f111f18583d049649b660ec8.png)
软件版本管理规范软件版本管理规范是指对软件开发过程中的版本进行管理的一系列规定和措施。
版本管理规范的目的是为了保持软件开发过程的稳定性和可控性,确保软件的质量和可靠性。
一、版本号命名规范1. 版本号由主版本号、次版本号和修订版本号组成,格式为“主版本号.次版本号.修订版本号”。
2. 主版本号表示重大功能改变或架构改变,增1。
3. 次版本号表示新增功能或重要的bug修复,增1。
4. 修订版本号表示小的改动或bug修复,增1。
5. 版本号从1开始,多次迭代后主版本号不变,次版本号递增,修订版本号保持从1开始递增。
二、版本控制规范1. 使用版本控制工具对源代码进行管理,例如Git、SVN等。
2. 每个项目创建独立的分支,主分支用于稳定版本发布,开发分支用于功能开发和bug修复。
3. 每个开发人员在自己的独立分支上进行开发,开发完成后将代码合并到开发分支,测试通过后再合并到主分支。
4. 每个版本发布前,对代码进行全面的测试,包括单元测试、集成测试和系统测试。
三、文档管理规范1. 每个版本发布前,编写相应的版本发布说明文档,包括版本改动内容、新增功能、修复bug等。
2. 所有的文档都要进行版本管理,与代码版本相对应。
3. 每个版本发布后,要及时更新相应的文档,包括用户手册、API文档等。
四、发布规范1. 每个版本发布前,要进行严格的测试,确保软件的质量和稳定性。
2. 每个版本发布时,要记录发布日期、发布人、版本号等信息。
3. 发布后要及时更新版本控制工具,将发布的版本标记为稳定版本。
五、变更管理规范1. 每个版本开发过程中,要及时记录相关的变更信息,包括功能变更、bug修复等。
2. 对于关键的变更,要在团队内进行讨论和评审,并及时通知相关人员。
总之,软件版本管理规范是保持软件开发过程稳定和可控的重要手段。
通过合理的版本号命名、版本控制、文档管理、发布规范和变更管理,能够更好地管理软件版本,提高软件开发的效率和质量。
软件版本管理规范V2
![软件版本管理规范V2](https://img.taocdn.com/s3/m/e51b120ece84b9d528ea81c758f5f61fb7362819.png)
软件版本管理规范V21. 引言软件版本管理是指对软件开发过程中各个版本的控制,以确保软件的可靠性、稳定性和可维护性。
本规范旨在建立一个统一的软件版本管理流程,规范开发人员在软件版本控制方面的操作和行为。
2. 基本原则2.1 版本命名规则版本命名采用主版本号.次版本号.修订版本号的格式,例如:1.0.0。
- 主版本号:当进行重大改动和功能新增时,递增主版本号。
- 次版本号:当进行小的修改和功能调整时,递增次版本号。
- 修订版本号:当进行bug修复和性能优化时,递增修订版本号。
2.2 版本控制工具使用专业的版本控制工具,如Git、SVN等。
版本控制工具能够记录软件的变更历史、回滚操作、分支管理等,方便团队合作和代码的版本控制。
2.3 分支管理策略采用分支管理策略可以实现多人协作开发,减少代码冲突的风险。
- 主分支:用于发布稳定版本的分支,命名为master或main。
- 开发分支:用于日常开发的分支,命名为develop。
- 功能分支:用于开发特定功能的分支,命名为feature/功能名称。
- 修复分支:用于修复bug的分支,命名为bugfix/bug编号。
- 发布分支:用于发布版本的分支,命名为release/版本号。
2.4 版本发布流程- 开发人员从develop分支创建功能分支,开发和测试功能。
- 开发完成后,将功能分支合并到develop分支。
- 当develop分支中的功能积累到一定程度时,从develop分支创建发布分支。
- 在发布分支上进行测试、修复bug,并最终合并到master分支发布版本。
- 同时将master分支的代码合并到develop分支,保证两个分支的同步。
2.5 版本文档管理每个版本需要编写相应的版本文档,包括版本号、发布日期、主要改动内容、已知问题等信息,方便用户了解和使用软件。
3. 版本管理流程3.1 新建项目创建新项目时,使用版本控制工具创建项目仓库,并上传初始代码。
软件版本管理规范
![软件版本管理规范](https://img.taocdn.com/s3/m/067bb43a6d175f0e7cd184254b35eefdc9d31570.png)
文件制修订记录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文件范例客户培训签到表项目名称:_________________________课程名称:_________________________ 日期: ______________。
CKT项目软件版本号命名规范
![CKT项目软件版本号命名规范](https://img.taocdn.com/s3/m/7e29b0ff5acfa1c7aa00cced.png)
CKT项目软件版本号命名规范软件命名规则:项目名称_客户代码_语言标示_版本号_版本发放日期_LCD信息_Camera信息_MCP信息_TF卡座信息_NandFlash信息_BlueT ooth蓝牙信息_FM收音机信息_Flashlight闪光灯信息_G Sensor加速度传感器信息_IRW红外信息_TV Out电视输出信息1、项目名称:根据CKT市场项目一览表来定义,如Leopard6-08、Ealge6-06等;对于研发过程中的就直接写项目名称,如Crocodile即可2、客户代码:根据CKT市场项目一览表来定义,如ES、CECT等;对于研发过程中还没有客户的直接写CKT即可3、语言标示:四位字母,XNYY,其中X为L表示Language的缩写;YY表示默认语言,如SM代表简体中文、TR代表繁体中文、RU代表俄文等;N表示有多少种语言,比如,简体中文+英文,则N等于2,简体中文+俄语+英语,则N等于34、版本号:三位数字,XYY,其中X为1或2 ,其中1代表测试软件,2代表量产软件,YY为版本流水号5、版本发放日期:六位数字,YYMMDD,第1、2位代表年,第3、4位代表月,第5、6位代表日,如0609216、LCD:六位字母,XXXYYY,前三位XXX代表Main LCD供应商,如ID0、TR0、LD0、SS0等;后三位YYY代表Sub LCD供应商,如果Main 和Sub共供应商就写两次,如IDWIDW,若无Sub则仅有三位字母,如ID07、Camera:2位字母加1位数字,XXY,前2位为字母代表Sensor 厂家,如OV代表OV Camera、SS代表三星Camera、HY代表现代Camera 等,第3位数字为像素,如0代表30万、1代表130万、2代表200万;对于Camera中同一Camera因为供应商不同导致视角不同的,请在此三位数后再加一个符号“Z”,如BMV项目用的Truly供应商封装的OV7660需要做180度的翻转,表示为“OV0Z”8、MCP:四位字母,XXYZ,前2位为厂家信息,如SP代表Spansion、IN代表Intel、SS代表Samsung等;后2位为Nor及PSRAM容量,前一位是Nor,后一位是PSRAM,命名规则为以2为底的幂,如4代表16Mb、5代表32Mb、6代表64Mb、7代表128Mb9、TF卡座信息:三位字母,XYY,如HTF表示热插拔TF卡座、CTF 表示冷插拔TF卡座,没有就不写10、NandFlash信息:两位字母,XX,有Nand就写ND,没有就不写11、BlueTooth蓝牙信息:两位字母,XX,有BlueTooth就写BT,没有就不写12、FM收音机信息:两位字母,XX,有FM收音机就写FM,没有就不写13、Flashlight闪光灯信息:两位字母,XX,有Flashlight闪光灯就写FL,没有就不写14、G Sensor加速度传感器信息:两位字母,XX,有G Sensor加速度传感器就写GS,没有就不写15、IRW红外信息:两位字母,XX,有IRW红外就写IR,没有就不写16、TV Out电视输出信息:两位字母,XX,有TV Out电视输出就写TV,没有就不写备注:“NandFlash信息、BlueTooth蓝牙信息、FM收音机信息、Flashlight 闪光灯信息、G Sensor加速度传感器信息、IRW红外信息、TV Out电视输出信息”对于这些可选硬件配置,如果软件中有的就用相应的两位字母表示,没有的就不用,但有的顺序一定要以上规定的处理,如同时有NandFlash和BlueTooth和G Sensor功能是,软件版本表示为“_ND_BT_GS”。
项目版本管理规范
![项目版本管理规范](https://img.taocdn.com/s3/m/2e09d0e00129bd64783e0912a216147916117e4c.png)
项目版本管理规范一、引言项目版本管理是指对项目中的软件版本进行统一管理和控制,确保项目的稳定性、可靠性和可维护性。
本文旨在制定项目版本管理规范,明确项目版本管理的流程、责任和要求,以确保项目的顺利进行。
二、版本管理流程1. 版本命名规范- 版本号由主版本号、次版本号和修订号组成,格式为x.y.z。
- 主版本号:当项目进行重大改版或者增加重要功能时,主版本号增加1。
- 次版本号:当项目进行功能增加或者修改时,次版本号增加1。
- 修订号:当项目进行错误修复或者小的改动时,修订号增加1。
- 例如,1.0.0表示第一个发布版本,1.1.0表示在第一个发布版本基础上增加了功能,1.1.1表示在1.1.0版本基础上进行了修订。
2. 版本控制工具选择- 选择一款适合项目的版本控制工具,如Git、SVN等。
- 在项目开始之前,团队成员应熟悉并掌握版本控制工具的基本操作和常用命令。
3. 分支管理- 主分支:用于发布稳定版本的分支,只包含经过测试和验证的代码。
- 开辟分支:用于开辟新功能的分支,团队成员在此分支上进行开辟和测试。
- 特性分支:用于开辟特定功能的分支,从开辟分支上创建,完成后合并回开辟分支。
- 修复分支:用于修复紧急bug的分支,从主分支上创建,完成后合并回主分支。
4. 版本发布流程- 开辟人员在开辟分支上进行开辟和测试。
- 开辟完成后,将代码合并到主分支,并进行集成测试和验收测试。
- 经过测试和验证无误后,将主分支上的代码打上标签,标记为发布版本。
- 发布版本的代码部署到生产环境,并进行线上测试和监控。
5. 版本回滚流程- 当线上浮现严重bug或者功能故障时,需要进行版本回滚。
- 回滚时,将生产环境的代码替换为上一个稳定版本的代码。
- 同时,需要记录回滚的原因、时间和操作人员,以便后续分析和处理。
三、版本管理责任1. 项目经理- 负责制定版本管理规范,并组织实施。
- 确保团队成员熟悉并遵守版本管理规范。
软件版本管理规范
![软件版本管理规范](https://img.taocdn.com/s3/m/d2d1b16e3069a45177232f60ddccda38376be185.png)
软件版本管理规范本文档旨在规范软件开发过程中的版本管理,确保版本控制的一致性和可追溯性,提高团队协作效率和产品质量。
1. 版本管理概述版本管理是软件开发过程中必不可少的一环,它可以追踪和控制软件的不同版本和变更。
一个好的版本管理系统能够帮助团队成员协同工作、追溯问题和修复bug,同时也有助于与客户或用户之间的沟通和交流。
2. 版本号命名规则在版本管理中,给每个软件版本分配一个唯一的版本号是非常重要的。
合理的版本号命名规则可以减少混乱和误解,并且方便了版本之间的比较和操作。
在我们的版本管理规范中,我们采用以下命名规则:•主版本号(Major Version):当软件有重大更新或变革时,递增主版本号。
•次版本号(Minor Version):当软件新增功能或有较大的改进时,递增次版本号。
•修订号(Patch Version):当软件修复bug或进行较小的改动时,递增修订号。
例如,一个版本号可能是1.2.3,其中1是主版本号,2是次版本号,3是修订号。
3. 分支管理策略在团队协作中,使用分支管理策略可以使开发工作有条不紊地进行,同时减少冲突和代码丢失的风险。
以下是我们的分支管理策略:•主分支(Master):主分支存放着稳定的、可发布的代码。
只有在确保代码质量和功能完整性的情况下,才能将代码合并到主分支中。
•开发分支(Develop):开发分支是团队成员进行日常开发的主要分支。
所有新功能的开发和bug修复都应该在开发分支上进行。
•功能分支(Feature branches):功能分支用于开发特定的功能或模块。
当新增功能或解决较大问题时,从开发分支上创建一个新的功能分支进行工作,并在完成后合并到开发分支中。
•修复分支(Hotfix branches):修复分支用于紧急修复主分支上的bug。
当发现主分支上的问题需要立即解决时,从主分支上创建一个新的修复分支进行工作,并在完成后合并到主分支和开发分支中。
4. 版本控制工具版本管理需要借助专业的版本控制工具来实现。
项目文件命名规范
![项目文件命名规范](https://img.taocdn.com/s3/m/7524e97ebf1e650e52ea551810a6f524ccbfcb34.png)
项目文件命名规范在进行项目管理过程中,项目文件的命名规范是非常重要的。
一个良好的命名规范可以提高团队成员之间的沟通效率,减少文件管理的混乱,并且有助于整个项目的顺利进行。
本文将介绍一些常用的项目文件命名规范,并给出一些建议。
一、文件命名原则1. 有意义:文件名应该能够准确地反映出文件的内容和用途。
避免使用无意义的数字或字母组合作为文件名。
2. 简洁明了:文件名应该尽量简洁明了,避免过长的文件名。
可以使用缩写、关键词等方式使文件名更加简明扼要。
3. 规范统一:项目组成员应遵循相同的文件命名规范,以便于团队成员间的相互理解和协作。
4. 可读性强:文件名应该具有良好的可读性,方便项目成员阅读和理解文件内容。
二、常用的文件命名规范1. 项目计划文件项目计划文件通常为 Microsoft Project 或其他项目管理软件生成的文件,可以按照以下格式命名:[项目名称]_[版本号]_[日期].mpp示例:项目A_V1.0_20220316.mpp2. 需求文档或功能规格说明书针对项目的需求文档或功能规格说明书,可以按照以下格式命名:[项目名称]_[文档类型]_[版本号]_[日期].docx示例:项目A_需求文档_V1.0_20220316.docx3. 会议纪要项目会议纪要按照以下格式命名:[会议日期]_[会议主题]_Meeting Notes_[会议编号].docx示例:20220316_项目A_会议纪要_Meeting Notes_001.docx4. 测试文档测试文档可以按照以下格式命名:[项目名称]_测试计划_[版本号]_[日期].docx示例:项目A_测试计划_V1.0_20220316.docx5. 用户手册或操作指南用户手册或操作指南可以按照以下格式命名:[项目名称]_用户手册_[版本号]_[日期].pdf示例:项目A_用户手册_V1.0_20220316.pdf6. 项目报告项目报告可以按照以下格式命名:[项目名称]_项目报告_[报告类型]_[日期].docx示例:项目A_项目报告_进展报告_20220316.docx三、文件命名的其他建议1. 使用英文命名文件,避免使用中文或其他特殊字符。
版本命名规则范文
![版本命名规则范文](https://img.taocdn.com/s3/m/58ad9d7142323968011ca300a6c30c225901f0ca.png)
版本命名规则范文以下是一些常见的版本命名规则:1.流水号版本命名法:按照时间顺序进行版本命名,通常形如v1.0、v2.0、v3.0等。
这种方式简单明了,容易理解和使用。
2. 主次版本号命名法:由两个数字组成,第一个数字表示主版本号,第二个数字表示次版本号。
主版本号的增加通常代表着较大的改动和功能升级,次版本号的增加通常表示小的改动或修复bug。
例如1.0、2.1、3.5等。
3.大版本号命名法:将版本号的第一个数字作为大版本号,后续的数字表示小版本号或修复补丁。
例如10.0、11.0、12.0等。
大版本号的增加通常表示较大规模的重大改动和功能新增。
4.编译号命名法:在版本号后面加上一个数字或者字母作为编译号,用于标记编译的次数。
例如v1.0.1、v2.3.4等。
5.年份标识命名法:使用年份作为版本的命名,通常结合其他命名规则一起使用。
例如2024.1、2024.2等。
除了上述常见的版本命名规则外,还可以根据具体需求和项目特点制定更具体的版本命名规则。
无论采用何种命名规则,都应该考虑以下几个因素:-清晰和易懂:版本命名应该能够清晰地传达版本的主要特点和差异,使用户和开发者能够快速理解其含义。
-有序性:版本命名应该有一定的有序性,便于排序和比较版本的新旧。
-可扩展性:版本命名规则应该具备一定的可扩展性,能够适应软件发展过程中的不断变化和更新。
-一致性:不同的软件项目应该遵循相同的版本命名规则,以保持一致性和统一性。
这有助于用户理解和使用不同软件之间的版本。
总的来说,版本命名规则应该能够准确传达版本的特点和差异,方便用户理解和使用,同时也要考虑到软件项目的具体需求和特点。
【项目管理知识】软件项目版本号的命名规则及格式介绍
![【项目管理知识】软件项目版本号的命名规则及格式介绍](https://img.taocdn.com/s3/m/765e5ea258fb770bf78a5592.png)
软件项目版本号的命名规则及格式介绍版本控制比较普遍的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:名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。
这适用于修复以前发布的程序集中的安全漏洞。
软件产品版本管理规范完整版
![软件产品版本管理规范完整版](https://img.taocdn.com/s3/m/bd69253d6fdb6f1aff00bed5b9f3f90f76c64ddb.png)
程序文件、版本需求相关 记录、开发相关记录、测 试相关记录、版本情况及 已知问题说明、使用反馈 记录、发布确认记录等
6
程序名命名规则:ቤተ መጻሕፍቲ ባይዱ
项目名称_产品名称+版本号_地区名首大写拼音(或其它备注,无就不写) 例:Aries_RZAPP1.1.18_0103_SH;Ow1.1.30.0104_BJ;Odnis1.1.20.0106
5
04 版本存档方式
测试过程版本——共享
测试通过版本——SVN
程序、版本需求相关记录、开 发相关记录、测试相关记录等
软件产品版本规范
版本规范
目 录
01 目的概述 02 版本梳理过程 03 版本命名规则 04 版本存档方式
2
01 目的概述
为什么要进 行规范?
统一规则,清晰、直观,利于继承性与归档管理。
在哪些方面 规范?
测试过程版本,测试通过版本。
3
02 版本梳理过程
4
03 版本命名规则
版本号格式规则:
主版本号:当功能模块有较大的变动,需要进行立项讨论,产品在立项成功后确定主版本号; 次版本号:用流水号表示,次版本号变更由三种情况确定 (1、需求重大变更;2、产品里程碑变换;3、产品重大缺陷导致需要短期强制要求实施更新); 修订版本号:程序迭代的流水号,属于日常修复BUG或者代码优化等,研发人员自主; 日期版本号:取日月 对于主版本号、次版本号、修订版本号三者,上一级有变动时,下一级版本号要归1。
项目版本管理规范
![项目版本管理规范](https://img.taocdn.com/s3/m/8fa4b557c4da50e2524de518964bcf84b8d52d6d.png)
项目版本管理规范引言概述:项目版本管理规范是软件开辟过程中非常重要的一环,它能够确保项目的稳定性和可追溯性。
本文将从版本管理的背景和意义出发,详细介绍项目版本管理规范的四个部份,包括版本命名规范、版本控制工具选择、分支管理策略和发布规范。
一、版本命名规范1.1 版本号命名规则:遵循主版本号.次版本号.修订号的格式,主版本号表示重大功能改进,次版本号表示小功能改进或者bug修复,修订号表示小的改动或者补丁。
1.2 预发布版本和正式版本的区分:使用alpha、beta、rc等标识来区分预发布版本和正式版本,alpha表示内部测试版本,beta表示公测版本,rc表示候选版本。
1.3 版本号的递增规则:根据版本的重要性和稳定性递增,保证版本号的一致性和可读性。
二、版本控制工具选择2.1 集中式版本控制工具 vs 分布式版本控制工具:根据项目的规模和团队的协作方式选择适合的版本控制工具,集中式适合小型项目,分布式适合大型项目。
2.2 常用的版本控制工具:介绍主流的版本控制工具,如Git、SVN等,分析它们的特点和适合场景。
2.3 版本控制工具的配置和使用规范:包括代码仓库的创建和管理、分支的创建和合并、冲突解决等,确保团队成员能够正确使用版本控制工具。
三、分支管理策略3.1 主分支和开辟分支的划分:主分支用于发布稳定版本,开辟分支用于日常开辟,保证开辟和发布的独立性。
3.2 功能分支和bug修复分支的管理:根据需求和bug的紧急程度创建相应的分支,确保不同功能和修复的代码不互相影响。
3.3 分支的合并和冲突解决:定期合并开辟分支到主分支,处理合并冲突,保证代码的一致性和稳定性。
四、发布规范4.1 发布前的测试和验证:在发布前进行全面的测试,包括单元测试、集成测试和系统测试,确保发布的版本质量。
4.2 发布的时间和频率:根据项目的需求和团队的开辟节奏确定发布的时间和频率,避免频繁发布和不必要的延迟。
4.3 发布的文档和记录:发布时要及时更新版本的文档和记录,包括版本的变更内容、发布的日期和负责人等信息,方便后续的追溯和管理。
package.json version规则
![package.json version规则](https://img.taocdn.com/s3/m/67c1d2b8710abb68a98271fe910ef12d2bf9a959.png)
package.json是Node.js项目中的一个重要文件,它用来管理项目的依赖、脚本和相关配置。
在package.json中,version字段是非常重要的,它用来指定项目的版本号。
在实际项目中,对于version的规则有着一定的要求和约定,以下是关于package.json version规则的相关内容:一、版本号格式在package.json中,版本号通常采用“主版本号.次版本号.修订号”的格式,例如:"version": "1.0.0"。
其中,主版本号指的是当你做了不兼容的API修改时,次版本号表示在保持向后兼容的情况下增加新功能,修订号则表示在保持向后兼容的情况下进行了bug修复。
二、语义化版本控制在制定版本号时,语义化版本控制是一个重要的原则。
语义化版本控制是一种软件版本号命名的规范,通过版本号来表达出软件的向下兼容性。
在Node.js项目中,语义化版本控制非常重要,因为它能够让开发者清楚地了解到版本号的含义,确保在更新依赖时不会出现意外的不兼容问题。
三、版本范围在package.json中,除了指定具体的版本号外,还可以通过指定版本范围来管理项目的依赖。
常用的版本范围包括"^1.0.0"、"~1.0.0"、">=1.0.0 <2.0.0"等,它们分别表示可以接受1.0.0以上但不包括2.0.0的任意版本、可以接受1.0.0版本及其修订版本的任何更新、可以接受1.0.0及以上但小于2.0.0的任意版本。
四、语义化版本范围与版本号类似,语义化版本范围也是一种重要的约定,它能够帮助开发者更好地管理项目的依赖关系。
在package.json中,通过语义化版本范围,可以指定依赖的最小版本、最大版本以及允许的更新类型,保证项目的相互依赖关系不会因为依赖的更新而出现意外的不兼容问题。
软件项目版本号的命名规则及格式
![软件项目版本号的命名规则及格式](https://img.taocdn.com/s3/m/60c707c085254b35eefdc8d376eeaeaad1f3168b.png)
软件项⽬版本号的命名规则及格式版本控制⽐较普遍的 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、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件项目版本号的命名规则及格式版本控制比较普遍的 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) 更新。
版本号管理策略一、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 -- 多语言版。