# **通用开发计划时间表**

**目录**

- [社区版本节奏](#社区版本节奏)
- [开发里程碑和质量策略](#开发里程碑和质量策略)
- [社区通用开发计划时间表](#社区通用开发计划时间表)
  - [开发计划时间表说明](#开发计划时间表说明)
  - [变更策略](#变更策略)
  - [应急计划](#应急计划)
- [维护时间表](#维护时间表)
- [生命周期终止](#生命周期终止)



## 社区版本节奏

openEuler项目大约每6个月发布一次社区新版本。社区新版本有两类，一类是创新版本，一类是长期维护版本。两类的差别请参考：[openEuler社区版本规划说明](version-plan.md)。

这里说的大约6个月，并不一定严格执行。因为社区版本的发布，依赖于版本准备期间的计划和质量达成情况，正式发布版本前，版本必须经过测试被证明是符合openEuler发布标准的，才会被正式发布。如果这个过程中有一些突发或异常情况，发行的时间有可能延迟。

具体到一个openEuler社区发布版本的计划时间表，请查看[版本开发计划公告文件夹]()。



## 开发里程碑和质量策略

openEuler社区版本开发周期的6个月内，多个团队会参与社区版本的开发和集成发布活动。为了更好的协调这些团队之间的活动，保证社区版本能够满足要求的顺利发布，我们定义了社区版本开发的里程碑和质量策略，具体请参考：[社区版本开发里程碑和质量策略说明](update-policy.md)。**开发时间表就是描述这些里程碑之间的时间线关系**。



## 社区通用开发计划时间表

发布经理会使用下面列出的关键任务和里程碑时间表制定社区版本的开发计划。各开发小组围绕这些日期制定详细的团队计划。下表是社区通用开发计划建议：



|      | 里程碑点             | 时间                                                        | 备注                         |
| ---- | -------------------- | ----------------------------------------------------------- | ---------------------------- |
| 1    | 需求提案收集启动日   | 上一版本需求截止日+1                                        | 可以根据情况灵活调整         |
| 2    | **项目启动日**       | 上一版本正式发布日+1天                                      |                              |
| 3    | 需求提案冻结日       | 星期二：项目启动日后两周                                    |                              |
| 4    | 迭代一检查点         | 星期二：项目启动日后六周                                    |                              |
| 5    | **内核冻结日**       | 星期二：项目启动日后十周                                    | 核心软件包需求完成           |
| 6    | 迭代二检查点         | 内核冻结日当天                                              |                              |
| 7    | 需求交付冻结日       | 星期二：拉分支点前4周                                       | 基础软件包需求完成           |
| 8    | 迭代三检查点         | 需求交付冻结日当天                                          |                              |
| 9    | **拉分支日**         | 星期二：β版本发布前3周                                      | NA                           |
| 10   | 迭代四检查点         | 星期二：拉分支日当天                                        | NA                           |
| 11   | **β冻结日**          | 星期二：β版本发布目标前1周                                  | QA执行β测试流程至β发布       |
| 12   | 100%代码完成         | β冻结日当天                                                 | NA                           |
| 13   | β发布评审会议        | 星期五：β版本发布日前3天                                    | NA                           |
| 14   | **β版本发布日**      | 周二：                                                      | 直到GA发布为止发布           |
| 15   | **正式版本冻结日**   | 周二：正式版本发布日前1周                                   | QA执行发布测试流程至最终发布 |
| 16   | 正式版本发布评审会议 | 星期五：正式版本发布日前3天                                 | NA                           |
| 17   | **正式版本发布**     | 星期二：该日期一般是4月1日之前一周或10月1日之前一周的星期二 | NA                           |
| 18   | 维护                 | 最终版本发布日                                              | ~6个月                       |
| 19   | 生命周期结束         | 下一个版本最终发布日后1个月                                 | NA                           |



### **开发计划时间表说明**

openEuler通常会在6个月内开发新的版本，以提供定期且可以预测的发布时间表。一年内两次的发布日期一般会定在3月底和9月底，以尽量错开重大的节假日。对此标准的更改必须得到openEuler技术委员会的批准。

尽管由于计划过程和发布验证周期的规定，openEuler也并不严格基于时间完成发行，而是会综合考虑时间、范围和质量等要素。

### 变更策略

由于各种因素的影响，很可能在关键里程碑点上无法满足计划要求。但openEuler社区的版本发行还是遵从：**高铁机制、质量优先的策略**。

- 原则上不变更版本发布的计划时间，尽量保证准点发布
- 不满足质量要求的软件包更新可以滑到下一个版本发布范围
- 影响较大的需求的延迟以至于影响到版本发布时间，需提交到技术委员会评估

### 应急计划

如果遇到未知问题等原因导致计划延迟，可以遵循以下应急计划：

- 如果“批量重建”未及时完成，可以将“分支点”时间以后的所有里程碑退后一周，以保证批量重建的完成。
- 如果“β发布评审会议”的结论为否，则里程碑调整可以遵循以下原则：
  - 单次调整方案一：增加“β版本发布目标2”，β计划增加一周，以完成目标2，不变动最终发布目标
  - 单次调整方案二：增加“β版本发布目标2”，β计划增加X周，以完成目标2，最终版本发布目标顺延。
  - 多次调整：（适用于后继的β发布目标也失败）调整β计划为“β版本发布目标N”，β计划增加X周，最终版本发布目标顺延。
- 如果“正式发布评审会议”结论为“否”，则最终版本发布目标延迟X周，其他计划不变。



## 维护时间表

所有创新版本只扩展支持维护6个月，我们的维护周期约7个月，这样安排是因为维护周期取决于下一个版本的发布日期。

如果您想要一个更加稳定、维护周期更长或者服务支持更好的发行版本，openEuler社区的LTS版本（它是openEuler派生或重新集成的版本）可能更适合您。所有LTS版本全面支持维护到下一个LTS版本正式发布（2年），再扩展支持维护（2年）



## 生命周期结束

当社区不再为某个发行版发布任何更新的时候，这个版本就意味着生命周期结束（EOL）。你可以在历史版本中[下载](https://openeuler.org/zh/download.html)。生命周期结束的版本不再提供维护支持 和 升级到更新版本的建议。

