# 社区版本开发里程碑和质量策略说明

openEuler社区版本开发周期一般是6个月。在这6个月内，多个团队会参与社区版本的开发和集成发布活动，所以为了更好的协调多个团队之间的活动，保证社区版本能够满足要求的顺利发布，我们定义了社区版本开发的里程碑和质量策略。

本文就是想大家详细介绍这些里程碑的设置时间、目的、期间具体的活动，以及软件包更新的质量策略。



目录：

- [社区版本开发里程碑图例](#社区版本开发里程碑图例)
- [里程碑和质量策略说明](#里程碑和质量策略说明)
  - [里程碑1：需求提案收集启动日](#需求提案收集启动日)
  - [里程碑2：新版本启动日](#新版本启动日)
  - [里程碑3：需求提案冻结日](#需求提案冻结日)
  - [迭代点说明](#迭代点说明)
  - [里程碑4：内核冻结日](#内核冻结日)
  - [里程碑5：需求冻结日](#需求冻结日)
  - [里程碑6：拉分支日](#拉分支日)
  - [里程碑7：β冻结日](#β冻结日)
  - [里程碑8：β发布](#β发布)
  - [里程碑9：正式发布冻结日](#正式发布冻结日)
  - [里程碑10：正式发布](#正式发布)



## 社区版本开发里程碑图例

**社区版本开发里程碑**

​            ![img](figure\openEuler社区版本发布计划时间表示意图.png)            

## 里程碑和质量策略说明

### 需求提案收集启动日

openEuler社区的新版本需求收集由发布经理主导。新版本需求收集的启动时间一般在上一个版本拉分支日。

在该时间点发布经理会在社区公告需求收集启动计划。具体请参考[版本需求规划和开发流程](requirement-development.md)相关章节。



### 新版本启动日

上一版本的正式发布日就是下一版本的启动日。在该时间点，发布经理会正式向社区公告新版本的具体开发时间表。该时间表用于：

- 开发团队把新需求的交付计划匹配到新版本的具体开发迭代点。
- 了解版本的各冻结点的时间
- 了解版本的测试计划和发布时间

获取最新的版本开发时间表，请访问发布经理的[发布时间表文件夹]()。



### 需求提案冻结日

新版本正式启动四周后，发布经理会完成新版本的需求收集工作，并进入，“需求提案冻结日”。在该时间点，发布经理会把收集到的**[新需求提案清单]()**向社区正式公告，并提交到技术委员会备案。



### 迭代点说明

从新版本启动，到拉发布分支，大致会经历4个半月的时间。为了便于在需求上线过程中各团队之间实现高效配合，这四个月的开发时间段被分成了**四个迭代**。大部分的需求上线时间均应落入四个迭代内。

在每一个迭代检查点，发布经理会检查需求上线计划的执行情况，并将执行情况向社区公告。



> **分支类型说明**
>
> openEuler使用的开发系统包含两个分支。
>
> - **开发主干**：开发分支是一个不断滚动向前开发的主干，也就是常说的“master”。
> - **发布分支**：openEuler的版本不会直接从开发分支上构建。在openEuler新版本发布前的约1个半月，新版本的分支会从开发主干上“拉出，作为该版本的发布分支。开发分支会继续向前开发。发布分支进入发布前的相关测试活动并逐渐稳定下来直至发布。

> **软件包类型说明**（软件包的分类说明待包管理小组补充）
>
> openEuler把软件包分为三种类型：
>
> - 核心软件包：包括kernel、XXX等及其依赖包，此类包XXXXXXXX
> - 基础软件包：
> - 外围软件包
>
> 可以通过XXXX方法查询一个软件包的类型



### 内核冻结日

内核冻结日一般在需求提案冻结日的8周后，同时和**迭代检查点二**重合。**从内核冻结日开始，开发主干进入冻结期**，执行冻结期的相关质量策略，并启动α测试。

该时间点离拉分支时间点还有大致两个月，在这两个月内，**maintainer需要执行**：

- 尽量不要推送会破坏每日构建的包，所有每日构建发现，并被QA团队标记为“阻塞”的bug，应尽快解决

- 如果包含ABI或API接口变更，因提前至少一周告知收影响的领域或团队，并得到影响团队的认可。如有争议需向技术委员会申请仲裁

- 如果更新后需要大量Rebuild，要至少提前三天向构建团队提交Issue申请

  如何更新软件包，请参考：[软件包更新指南]()

**设置此时间点是为了保证：**

- 核心软件包先稳定下来
- 需要大量ReBuild的软件包先稳定下来

能够在这以后，构建出一个相对稳定的版本，为进入α测试做准备。同时控制住影响较大的变更，同时给这些变更预留出相对较长的测试稳定周期。

**在此时间点上的目标是：**

- 所有类型为**核心包**的软件包的需求应开发完毕并提交上线。
- 所有会引发系统大量Rebuild的变更应执行完毕。



### 需求冻结日

需求冻结日一般在内核冻结日后一个月，同时和**迭代检查点三**重合。

该时间点离拉分支点还有大致一个月时间，在这一个月内，**maintainer需要执行**：

- 尽量不要推送会破坏每日构建的包，所有每日构建发现，并被QA团队标记为“阻塞”的bug，应尽快解决
- 所有QA团队在α测试发现，并被标注上“阻塞”的bug，应尽快解决
- 如果包含ABI或API接口变更，因提前至少一周告知收影响的领域或团队，并得到影响团队的认可。如有争议，需向技术委员会申请仲裁

- 尽量避免需要大量Rebuild的变更。

**设置该时间点是为了保证：**

- 离发布日还有大致两个月时间，基础包应进入稳定周期。
- 系统级的接口变更先行确定下来

能够在这以后，对操作系统的基础场景进行较全面的验证，为一个月后拉发布分支做好准备。

**在此时间点上的目标是：**

- 基础包的大部分需求应该已经开发完毕并提交上线。

- 所有涉及到系统级的ABI/API接口应变更执行完毕。原则上，需求冻结日后不应在进行系统级的ABI/API接口变更。



### 拉分支日

拉分支日一般在需求冻结日后一个月，同时和迭代检查四（最后一个迭代）重合。拉分支日也意味着，新版本的需求进本已经开发完毕，进入冻结期后的α测试活动也同时结束，新版本转移到发布分支上进行发布前的各项集成测试活动。所以拉分支需要满足一定的条件，发布经理会根据[《拉分支前的Checklist》](branch-checklist.md)检查拉分支前各项活动的满足情况。



需求冻结日到拉分支日的一个月内，**maintainer需要**：

- 尽量不要推送会破坏每日构建的包；所有每日构建发现，并被QA团队标记为“阻塞”的bug，应尽快解决
- 所有QA团队发现，并被标注上“阻塞”的bug，应尽快解决

- 应尽量避免系统级的ABI或API接口变更

- 如果包含ABI或API接口变更，因提前至少一周告知收影响的领域或团队，并得到影响团队的认可。如有争议，需向技术委员会申请仲裁

**该时间点发布分支需要从开发主干拉出，所以要求：**

- 大部分的需求已经完成开发并提交上线。如果需要需要延后到拉分支日后提交，需要和发布经理达成一致。
- 所有的ABI或API接口变更应确定下来。

该时间点后，发布分支从开发主干拉出，**开发主干上的冻结期结束**。新版本的大部分的需求已经提交上线。发布分支以解决bug为主，为了避免开发主干和发布分支上的合入遗漏，**原则上修改bug应先在开发主干上完成，在开发主干上验证通过以后，再backport到发布分支上**。



### β冻结日

拉分支后两周进入β冻结日。这两周内，β相关测试活动已经基本完成，**maintainer需要执行的质量策略是：**

- 所有QA团队发现，并被标注上“阻塞”的bug，应尽快解决

- 所有软件包更新的操作，需至少有一个核心成员的+1

- 应尽量避免对周边有影响的接口变更

**为了保证β发布能够按时通过，在该时间点：**

- 需求已经100%交付完成
- 所有相关配套资料已经Ready

**在该时间点上的目标：有一个稳定的β发布版本，并可以启动β发布前的各项准备工作。**



### β发布

β冻结日后三天，发布经理会启动β发布评审会议；发布评审会议之前，发布经理会根据[《发布前的Checklist》](Release-checklist.md)检查β发布前的各项活动的满足情况。评审通过以后四天，会正式发布β版本。版本β发布以后，可以启动β版本的众测。

从β冻结到β发布，只有一周的时间，QA团队主要会执行稳定性的测试，同时各发布相关团队启动β发布前的准备工作。在此阶段：

- 所有的问题解决合入需要和QA团队沟通确认，且只解决标记为“block”的bug（问题Issue下的QA团队反馈）

- 所有的软件包更新的操作，需至少有两个核心成员的+1

**在该时间点上的目标：有一个满足要求的β发布版本，并完成正式发布。**



### 正式发布冻结日

β发布后一个月，进入正式发布的冻结。

这两周内，正式发布相关测试活动已经基本完成，**maintainer需要执行的质量策略**是：

- 所有QA团队发现，并被标注上“阻塞”的bug，应尽快解决

- 所有软件包更新的操作，需至少有两个核心成员的+1

- 应尽量避免对周边有影响的接口变更

**为了保证正式发布能够按时通过，在该时间点**：

- 需求已经100%交付完成
- 原则上所有阻塞发布的问题已经100%解决
- 所有相关配套资料已经Ready
- 所有发布配套的用户工具等已经Ready

在该时间点上的目标：有一个稳定的正式发布版本，并可以启动β发布前的各项准备工作。



### 正式发布

正式冻结日后三天，发布经理会启动正式发布评审会议；发布评审会议之前，发布经理会根据[《发布前的Checklist》](Release-checklist.md)检查正式发布前的各项活动的满足情况。评审通过以后四天，会发布正式版本。正式版本发布以后，可以在社区上下载到正式版本。