版本管理及流程

1、目的：

标识、控制、追踪软件开发过程中产生的各个软件产品版本

2、适用范围：

适用于软件源代码、产品版本的管理。

3、职责：

3.1、测试管理：

确保项目版本按照正确的版本管理规范执行和使用

3.2、研发管理员：

负责定期检查各项目对版本管理规范的执行度，根据发展需要对规范进行完善

3.3、项目管理员

负责项目软件产品版本管理规范的推行，指导项目组成员使用版本命名规范进行版本管理

4、版本号说明：

4.1、版本命名规则：

软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.20230131_beta。

4.2、版本号修改规则：

(1) 主版本号(1)：

当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由产品决定是否修改。

(2) 子版本号(1)：

相对于主版本号而言，子版本号升级对应的是软件功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由产品决定是否修改。

(3) 阶段版本号(1)：

一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由产品经理决定是否修改。

(4) 日期版本号(20230131)：

用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

(5) 希腊字母版本号(beta)：

此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

4.3、软件版本阶段说明：

(1) Base：开发周期版本：

开发阶段版本，主要在开发过程中还没有完善功能的情况下的版本，用于开发内部记录版本使用。

(2) α（Alpha）版：开发自测版本：

软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者 内部交流，或者专业测试人员测试用，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试服务让测试人员进行单元测试，此时可将软件版本标注为alpha版。

(3) β（Beta）版：交付测试版本：

该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI，提供给测试人员做全功能测试验证

(4) RC 版：预生产版本：

是 Release Candidate 的缩写，意思是发布倒计时，候选版本，该版本已经相当成熟了，完成全部功能并清除大部分的BUG，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。

(5) Release 版：生产版本：

该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。

(6) 流程图：

5、版本发布周期定义：

5.1、版本迭代类型：

• 正常周期内迭代版本（预估时间周期内日常测试版本）
• 需求变更BUG处理版本（例如使用过程中遇到灾难级问题需要立马重新发版的BUG）

5.2、递交版本流程：

(1) 固定周期版本：

1、固件版本：每周一版（暂定每周五晚上SLAM、PNC、SW提交代码通过自动构建打包OTA升级或生成版本手动烧录）

2、应用端版本：每日一版（暂定每天晚上APP提交代码通过自动构建打包发布）

3、服务端及IOT：每日一版（暂定每天晚上提交代码通过自动构建打包部署）

(2) 需求变更及blockBUG修复版本：

1、所有模块如出现灾难级bug影响功能测试，需即可发版，测试记录缺陷到jira记录，并将优先级置于最高，第一时间要求开发解决问题同时发版，并将block版本放弃在重新提交的新版本上继续进行测试工作。

(3) 其余情况版本：

除上述两个情况下发版，其余发版条件必须同步项目、产品、测试、开发所有人知晓确认，由大家一起评估是否暂停正在测试版本，因为在测试阶段，如果突然发布版本等于测试任务全部重新测试，之前版本直接放弃

5.3、发布流程图：