软件项目命名规范
项目命名及管理规范
项目命名及管理规范一、项目命名规范项目命名是项目管理中非常重要的一环，一个规范的项目命名可以提高项目的管理效率和沟通效果。
以下是项目命名的规范格式：1. 项目类型缩写-项目名称-项目编号例如：APP-在线购物平台-0012. 项目类型缩写可以根据实际项目类型进行选择，如APP、WEB、H5等。
3. 项目名称应简明扼要地描述项目的主要内容，避免使用过于宽泛或模糊的名称。
4. 项目编号是为了方便项目的唯一标识和管理，可以根据公司的实际情况进行编号。
5. 项目命名应使用英文或拼音，避免使用中文或特殊字符，以免造成不必要的麻烦。
二、项目管理规范项目管理是确保项目按时、按质、按量完成的关键，一个规范的项目管理流程可以提高项目的执行效率和管理质量。
以下是项目管理的规范要求：1. 项目启动阶段：- 制定项目章程，明确项目目标、范围、时间、成本、质量等基本要求。
- 成立项目组，确定项目组成员及其职责。
- 制定项目计划，明确项目工作内容、工期、资源需求等。
2. 项目执行阶段：- 按照项目计划进行任务分解，明确各个任务的负责人和完成时间。
- 进行项目进度和成本的监控，及时调整项目计划，确保项目按时、按质量完成。
- 建立项目沟通机制，保持项目组内外的沟通畅通。
3. 项目收尾阶段：- 完成项目交付物的验收，确保交付物符合预期要求。
- 撰写项目总结报告，总结项目经验和教训，为以后的项目提供参考。
- 进行项目评估，评估项目的绩效和效益，为公司的决策提供依据。
4. 项目管理工具：- 使用项目管理软件进行项目计划的编制和跟踪。
- 使用协同办公工具进行项目组内的协作和沟通。
- 使用文档管理系统进行项目文档的归档和管理。
5. 项目管理人员要求：- 具备良好的沟通和协调能力，能够有效地组织和管理项目。
- 具备一定的项目管理知识和经验，能够灵活运用项目管理工具和方法。
- 具备团队合作意识，能够有效地领导和激励项目组成员。
以上是项目命名及管理规范的详细内容，通过规范的项目命名和管理流程，可以提高项目的管理效率和执行质量，确保项目顺利完成。
软件产品名称命名规范
软件产品登记命名规则
1. 软件产品名称: 软件产品名称构成品牌+产品用途与功能
+“软件"+产品版本号。
定制软件产品名称构成:品牌+客户单位名称+产品用途与功能+“软件”+产品版本号。
2. 品牌：品牌中须包含软件产品厂商标识,亦可含产品标识，并
可应用外文字母或拼音字母.但在品牌中不可单独出现“中国”、“中华”、地方名等字样及其它专有名称。
3. 产品用途与功能：在本段中应以简明的方式表明该软件的运
用行业、用途与功能,不能笼统模糊，不准用全字母表示，如出现缩写须用括号标上，产品型号放在产品用途和功能前,不需加括号;国际公认的名称如LINUX、WINDOWS等可在该段中出现，不需用括号.
4. 产品版本号：软件产品的名称中必须表明VXX。
XXX字样的
版本号，其中X必须是具体数字,以年号和非标准式标明版本号的要做说明。
5. 软件产品外销名称可全用外文。
6. 该软件产品在办理著作权登记、产品测试和产品登记时名称
应一致。
项目命名及管理规范
项目命名及管理规范引言概述：在软件开辟和项目管理中，项目命名及管理规范起着至关重要的作用。
一个良好的命名规范可以提高项目的可读性和可维护性，同时也有助于团队成员之间的沟通和合作。
本文将介绍项目命名及管理规范的重要性，并详细阐述命名规范、项目管理规范、团队协作规范以及版本控制规范四个方面的内容。
一、命名规范：1.1. 变量和函数命名规范：变量和函数的命名应具有描述性，能够清晰地表达其用途和含义。
命名应使用故意义的英文单词或者缩写，避免使用拼音或者无意义的字符。
同时，应遵循统一的命名风格，如驼峰命名法或者下划线命名法。
1.2. 文件和目录命名规范：文件和目录的命名应简洁明了，能够准确反映其内容和用途。
应使用故意义的英文单词或者缩写，避免使用特殊字符或者过长的命名。
同时，应注意命名的大小写规范，以及统一的命名风格。
1.3. 数据库命名规范：数据库表、字段和索引的命名应具有一致性和可读性。
应使用故意义的英文单词或者缩写，避免使用拼音或者无意义的字符。
同时，应注意命名的长度和大小写规范，以及统一的命名风格。
二、项目管理规范：2.1. 项目计划和进度管理：项目管理应遵循明确的计划和进度安排，确保项目按时交付。
应制定详细的项目计划，包括任务分配、时间预估和里程碑安排。
同时，应及时跟踪和更新项目进度，及时调整计划和资源分配。
2.2. 需求管理和变更控制：项目需求应明确、具体和可测量。
应建立有效的需求管理机制，包括需求采集、评审和变更控制。
同时，应及时记录和跟踪需求变更，确保变更的合理性和可控性。
2.3. 质量管理和风险控制：项目质量管理应包括代码质量、测试质量和文档质量等方面。
应建立有效的质量控制机制，包括代码审查、单元测试和文档审核。
同时，应及时识别和评估项目风险，采取相应的风险控制措施。
三、团队协作规范：3.1. 沟通和协作方式：团队成员之间应建立良好的沟通和协作机制。
应定期召开会议，交流项目发展和问题解决方案。
计算机软件开发规范
计算机软件开发规范计算机软件开发规范在计算机软件开发过程中，遵循一定的规范是十分重要的。
软件开发规范可以确保开发出高质量、可维护和可扩展的软件，并提高团队的开发效率。
下面是一些常见的计算机软件开发规范。
1. 命名规范- 使用有意义的变量、函数和类名，不使用缩写和单音字母命名。
- 使用驼峰命名法或下划线命名法，例如camelCase或snake_case。
- 避免使用保留字作为命名。
- 命名应具有描述性，可以清晰地表达其用途。
2. 代码风格规范- 使用适当的缩进和空格使代码易于阅读。
- 使用恰当的注释来解释代码的作用和功能。
- 避免使用过长的行，一般限制在80-120个字符之间。
- 代码结构应清晰，使用适当的空行和代码块。
- 考虑使用代码格式化工具来统一代码风格。
3. 错误处理规范- 在代码中及时捕获和处理异常，避免程序崩溃或不可预测的行为。
- 使用合适的异常处理机制，包括抛出和捕获异常。
- 记录错误和异常信息，以便后续分析和修复。
4. 安全规范- 避免使用硬编码的敏感信息，如密码和私钥。
- 对用户输入进行验证和过滤，防止SQL注入和跨站脚本攻击等安全问题。
- 对涉及到敏感数据的处理进行加密保护。
5. 版本控制规范- 使用版本控制系统来管理代码，如Git或SVN。
- 提交代码前进行代码审查，确保代码质量和一致性。
- 使用适当的分支管理策略，如主分支和开发分支。
- 使用有意义的提交消息来解释代码变更。
6. 文档规范- 编写清晰、易于理解的代码注释。
- 编写高质量的用户文档和技术文档，包括安装指南、使用说明和API文档。
- 在代码库中提供README文件，介绍项目背景、使用方法和贡献指南。
7. 测试规范- 编写单元测试、集成测试和系统测试来确保代码的功能和稳定性。
- 使用自动化测试工具进行自动化测试。
- 分析测试覆盖率并完善测试用例，提高测试效果。
8. 性能规范- 编写高效的代码，避免不必要的计算和资源浪费。
项目命名及管理规范
项目命名及管理规范引言概述：在软件开辟和项目管理过程中，良好的项目命名和管理规范是非常重要的。
它们不仅能提高团队的工作效率，还能增加代码的可读性和可维护性。
本文将详细介绍项目命名及管理规范的五个部份，包括命名规范、项目结构规范、文档管理规范、版本控制规范和团队协作规范。
一、命名规范：1.1 变量和函数命名：- 使用故意义的名称，能够准确描述变量或者函数的用途。
- 遵循驼峰命名法，即首字母小写，后续单词首字母大写。
- 避免使用缩写和简写，除非是广为人知的缩写。
1.2 类和接口命名：- 使用名词或者名词短语命名类和接口。
- 遵循帕斯卡命名法，即每一个单词首字母大写。
- 避免使用与语言关键字相同的名称。
1.3 文件和目录命名：- 使用故意义的文件和目录名称，能够清晰表达其内容或者用途。
- 避免使用特殊字符和空格，使用连字符或者下划线代替。
- 文件名和目录名应保持一致，不要混用大小写和命名风格。
二、项目结构规范：2.1 目录结构：- 根据项目的功能和模块划分目录，保持结构清晰。
- 使用层次化的目录结构，方便查找和管理文件。
- 在根目录下添加README文件，对项目进行简要说明。
2.2 文件组织：- 将相关的文件放在同一个目录下，便于查找和维护。
- 使用故意义的文件名，能够准确描述文件的内容。
- 使用文件扩展名来标识文件类型，方便编辑器和开辟工具的识别。
2.3 构建和部署：- 使用构建工具来管理项目的依赖和构建过程。
- 将构建产物和部署文件放在指定的目录下，便于发布和交付。
三、文档管理规范：3.1 项目文档：- 编写项目文档，包括需求文档、设计文档和用户手册等。
- 使用统一的模板和格式，方便查阅和更新。
- 定期更新和维护文档，确保其与项目的实际情况保持一致。
3.2 注释：- 在代码中添加注释，解释代码的功能和实现细节。
- 使用清晰简洁的语言，避免过多的技术术语和专业名词。
- 注释应与代码同步更新，保持准确性和一致性。
项目命名及管理规范
项目命名及管理规范一、项目命名规范项目命名是对项目进行惟一标识和区分的重要方式，良好的项目命名规范能够提高项目管理的效率和可维护性。
以下是项目命名的规范要求：1. 项目名称应简洁明了，能够准确表达项目的主要内容和目标。
例如，一个软件开辟项目可以命名为“在线商城系统开辟”。
2. 项目名称应避免使用缩写词和简写，以免造成团队成员之间的理解差异。
例如，不要使用“OMS”代替“在线商城系统”。
3. 项目名称应使用英文单词或者词组，并使用驼峰命名法。
例如，“OnlineShoppingSystem”。
4. 对于多个阶段或者版本的项目，可以在项目名称中加入阶段或者版本信息，以便更好地管理和追踪项目的发展。
例如，“OnlineShoppingSystemV1.0”。
5. 在命名项目时，应避免使用特殊字符和空格，以免在后续的文件管理和代码编写过程中浮现问题。
二、项目管理规范良好的项目管理规范能够确保项目按时、按质、按量完成，并提高项目团队的协作效率。
以下是项目管理规范的要求：1. 项目计划管理- 制定详细的项目计划，包括项目的目标、范围、时间、成本、质量、风险等方面的内容。
- 定期更新和调整项目计划，及时反映项目发展和变更情况。
- 设立里程碑，明确项目的重要节点和关键任务。
2. 项目组织管理- 设立项目组织结构，明确项目团队成员的职责和权限。
- 确定项目团队的沟通渠道和协作方式，保证信息的畅通和团队的高效合作。
- 定期组织项目团队会议，及时沟通项目发展和问题，并制定解决方案。
3. 项目风险管理- 识别和评估项目的风险，制定相应的风险应对策略和计划。
- 定期进行风险监控和评估，及时采取措施应对潜在风险。
- 建立风险管理文档，记录和跟踪项目的风险情况和处理过程。
4. 项目质量管理- 制定项目质量管理计划，明确项目的质量目标和要求。
- 设立质量管理控制点，对项目过程和成果进行质量检查和评估。
- 建立质量管理文档，记录和跟踪项目的质量问题和改进措施。
软件产品命名规范建议
软件产品命名规范建议
根据信息产业部和税务部门的要求，软件产品中文名称必须规范，由三部分组成：公司的标识（公司简称即可，可用中、英文）、产品内容和产品属性（能体现这是一个软件产品的标识，如："软件"、"系统"、"平台"、"中间件"等字样）。
如范例：软协备案系统、金山词霸软件。
如产品名称还有简称的，请在简称前后加上中文的[ ]，统一个格式例如：金山词霸软件 [简称：金山词霸]
软件名称与版本号确认单
说明：、请明确被测试软件产品的全称及版本号，注意英文字母的大小写。
且必须与软件产品登记和软件企业认定申报表上填写的软件产品名称
和版本号相一致。
、请确定委托单位的全称；
、该确定单中的软件名称与版本号将与报告中的相一致。
自主产权保证书
本单位保证所提供的如下软件产品为本单位自主开发的软件产品，产权归本单位所有，保证提交的文件真实、合法，如有不实，本单位愿承担一切法律责任。
特此保证。
软件产品名称：
委托单位（盖章）：
单位法人（签名）：
日期：年月日。
项目命名及管理规范
项目命名及管理规范引言概述：在软件开发过程中，项目命名及管理规范是非常重要的，它不仅能提高团队协作效率，还能方便项目的维护和扩展。
本文将从项目命名规范、项目管理规范、版本控制规范、文档管理规范和代码规范五个方面详细阐述。
一、项目命名规范：1.1 项目名称：项目名称应简洁明了，能够准确表达项目的功能和目的。
避免使用缩写或过于复杂的词汇，以免给团队成员带来困扰。
1.2 文件命名：文件命名应具有描述性，能够清晰地表达文件的内容和作用。
采用驼峰命名法或下划线命名法，统一命名风格，便于团队成员的理解和查找。
1.3 目录结构：项目目录结构应合理划分，按照功能或模块进行分类，以便于团队成员的协作和维护。
同时，应遵循统一的命名规范，方便团队成员的理解和使用。
二、项目管理规范：2.1 项目计划：在项目启动阶段，制定详细的项目计划，包括项目目标、里程碑、资源分配等内容，明确项目的时间和质量要求，确保项目的顺利进行。
2.2 任务分配：根据项目计划，合理分配任务给团队成员，明确每个人的责任和工作内容。
同时，建立良好的沟通机制，及时了解项目进展和解决问题。
2.3 进度管理：定期进行项目进度的跟踪和评估，及时发现和解决项目中的问题和风险。
同时，建立项目管理工具，记录项目的进展和问题，方便团队成员的参考和回顾。
三、版本控制规范：3.1 分支管理：根据项目的需要，合理划分分支，如开发分支、测试分支和发布分支等。
每个分支应有明确的目的和规范的操作流程，确保代码的稳定性和可维护性。
3.2 提交规范：团队成员在提交代码时，应遵循统一的提交规范，包括提交信息的格式和内容要求。
提交信息应简洁明了，能够清晰地表达代码的修改内容和目的。
3.3 版本发布：在代码经过测试和审核后，进行版本的发布。
每个版本应有明确的版本号和发布说明，方便用户了解和使用。
同时，建立版本回退机制，确保项目的稳定性和可靠性。
四、文档管理规范：4.1 文档分类：根据项目的需要，将文档进行分类，如需求文档、设计文档和测试文档等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件项目命名规范篇一：软件项目版本号的命名规则及格式软件项目版本号的命名规则及格式版本控制比较普遍的 3 种命名格式 :一、GNU 风格的版本号命名格式 :主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]Major_Version__Version_Number[.Revision_Number[.Bui ld_Number]]示例 : , , build-13124二、Windows 风格的版本号命名格式 :主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]Major_Version__Version_Number[Revision_Number[.Buil d_Number]]示例: ,三、.Net Framework 风格的版本号命名格式:主版本号.子版本号[.编译版本号[.修正版本号]]Major_Version__Version_Number[.Build_Number[.Revisi on_Number]]版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。
主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。
所有定义的部分都必须是大于或等于 0 的整数。
应根据下面的约定使用这些部分：Major ：具有相同名称但不同主版本号的程序集不可互换。
例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。
例如，这适用于产品的修正版或完全向后兼容的新版本。
Build ：内部版本号的不同表示对相同源所作的重新编译。
这适合于更改处理器、平台或编译器的情况。
Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。
这适用于修复以前发布的程序集中的安全漏洞。
程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。
版本号管理策略一、GNU 风格的版本号管理策略：1．项目初版本时，版本号可以为或 , 也可以为或，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；2．当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；4．当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1； 5．另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
二、Window 下的版本号管理策略：1．项目初版时，版本号为或；2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；5. 另外 , 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
另外，还可以在版本号后面加入 Alpha、Beta、Gamma、Current、RC (Release Candidate)、Release、Stable 等后缀，在这些后缀后面还可以加入 1 位数字的版本号。
对于用户来说，如果某个软件的主版本号进行了升级，用户还想继续那个软件，则发行软件的公司一般要对用户收取升级费用；而如果子版本号或修正版本号发生了升级，一般来说是免费的。
=====附录软件版本名称=====α（alphal）内部测试版α版，此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。
一般而言，该版本软件的 bug 较多，普通用户最好不要安装。
β（beta）外部测试版该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的发布测试来进一步消除。
这一版本通常由软件公司免费发布，用户可从相关的站点下载。
通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。
该版本也不适合一般用户安装。
γ（gamma）版该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，尽可以装上一试。
trial（试用版）试用版软件在最近的几年里颇为流行，主要是得益于互联网的迅速发展。
该版本软件通常都有时间限制，过期之后用户如果希望继续使用，一般得交纳一定的费用进行注册或购买。
有些试用版软件还在功能上做了一定的限制。
uegistered（未注册版）未注册版与试用版极其类似，只是未注册版通常没有时间限制，在功能上相对于正式版做了一定的限制，例如绝大多数网络电话软件的注册版和未注册版，两者之间在通话质量上有很大差距。
还有些虽然在使用上与正式版毫无二致，但是动不动就会弹出一个恼人的消息框来提醒你注册，如看图软件acdsee、智能陈桥汉字输入软件等。
demo 演示版在非正式版软件中，该版本的知名度最大。
demo版仅仅集成了正式版中的几个功能，颇有点像 uegistered。
不同的是，demo版一般不能通过升级或注册的方法变为正式版。
以上是软件正式版本推出之前的几个版本，α、β、γ可以称为测试版，大凡成熟软件总会有多个测试版，如windows 98 的β版，前前后后将近有10个。
这么多的测试版一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量减少了软件中的bug 。
而 trial 、uegistered 、demo 有时统称为演示版，这一类版本的广告色彩较浓，颇有点先尝后买的味道，对于普通用户而言自然是可以免费尝鲜了。
正式版，不同类型的软件的正式版本通常也有区别。
release 最终释放版该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，对于用户而言，购买该版本的软件绝对不会错。
该版本有时也称为标准版。
一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号 (r) ，如 windows nt(r) 、ms-dos(r) 等。
registered 注册版很显然，该版本是与 uegistered 相对的注册版。
注册版、release和下面所讲的standard版一样，都是软件的正式版本，只是注册版软件的前身有很大一部分是从网上下载的。
standard 标准版这是最常见的标准版，不论是什么软件，标准版一定存在。
标准版中包含(转载于: 小龙文档网:软件项目命名规范)了该软件的基本组件及一些常用功能，可以满足一般用户的需求。
其价格相对高一级版本而言还是“平易近人”的。
deluxe 豪华版顾名思义即为“豪华版”。
豪华版通常是相对于标准版而言的，主要区别是多了几项功能，价格当然会高出一大块，不推荐一般用户购买。
此版本通常是为那些追求“完美”的专业用户所准备的。
reference该版本型号常见于百科全书中，比较有名的是微软的encarta系列。
reference是最高级别，其包含的主题、图像、影片剪辑等相对于standard和deluxe版均有大幅增加，容量由一张光盘猛增至三张光盘，并且加入了很强的交互功能，当然价格也不菲。
可以这么说，这一版本的百科全书才能算是真正的百科全书，也是发烧友们收藏的首选。
professional（专业版）专业版是针对某些特定的开发工具软件而言的。
专业版中有许多内容是标准版中所没有的，这些内容对于一个专业的软件开发人员来说是极为重要的。
如微软的visual foxpro标准版并不具备编译成可执行文件的功能，这对于一个完整的开发项目而言显然是无法忍受的，若客户机上没有foxpro将不能使用。
如果用专业版就没有这个问题了。
enterprise（企业版）企业版是开发类软件中的极品（相当于百科全书中的reference版）。
拥有一套这种版本的软件可以毫无障碍地开发任何级别的应用软件。
如著名的visual c++的企业版相对于专业版来说增加了几个附加的特性，如sql调试、扩展的存储过程向导、支持as/400对ole db的访问等。
而这一版本的价格也是普通用户无法接受的。
如微软的visual studios enterprise 中文版的价格为 23000 元。
其他版本，除了以上介绍的一些版本外，还有一些专有版本名称。
update（升级版）升级版的软件是不能独立使用的，该版本的软件在安装过程中会搜索原有的正式版，如果不存在，则拒绝执行下一步。
如microsoft office XX升级版、windows 9x升级版等等。
oem版篇二：软件版本命名规范版本命名规范软件版本阶段说明:Base版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为该软件的一个基础架构。
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。
一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
版本命名规范软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
例如：_beta。
版本号定修改规则主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。
此版本号由项目决定是否修改。
(次版本)偶数的次版本为经过严格测试的稳定版本，奇数的次版本则表示为不稳定的测试版本。
阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。
此版本号由项目经理决定是否修改。