背景 Link to heading
以前的系统发布模式为平均每3个月一次系统发布——开发周期2个月，测试周期1个月。这虽然保证了每次系统发布的状态都比较稳定，但是仍然避免不了在大量用户在不同场景下产生而发现新 BUG 的局面，而且因为这种发布模式缺少快速更新的机制，导致很多在内部已经得到修复的问题无法及时推送到外网，用户在这段时间内只能忍受一些 BUG 的干扰。所以，我们在 15.6 和 15.7 的时候引入了”发布后一个月“的概念，在这个时间段内，开发主要做问题修复工作，修复的内容可以快速推送到外网，而不用经过繁杂的测试，期望快速解决用户在使用新版本中遇到的问题，这就是深度滚动更新的原型。
15.8开发的过程中，我们又思考了一下这个过程，刚巧我们决定了要尝试”开放和透明“、拥抱社区，所以觉得目前这种把”大教堂“和”集市“两种开发模式揉在一起的方式不是特别明朗，对系统发布者和开发者都是一种负担，所以”从善如流“——从 15.9 开始，deepin 系统的发布开始遵循滚动更新的模式。
滚动更新流程 Link to heading
深度的滚动更新，需要参与系统发布的产品、开发和测试共同合作，所以制定了一套简单的工作流程作为大家协作的基础，从粗到细主要分为了以下几个范围：
1. 系统版本 Link to heading
系统版本的概念跟以前的 15.7、15.8 等没有不同，都会提前指定这 2 - 3 个月的一个工作计划，在阶段性工作完成之后，会有新版本的 ISO 发布。与之前不同的是，新功能不是等系统发布的时候一次性放出，而是在每周开发内容完成、测试通过以后就会放出；另外一个不同是，系统发布不再以完成所有开发内容为前提，而是在系统版本计划的时间点达到以后即发布，未完成的内容放入下个版本工作内容中。
工具使用：
- 系统版本规划的内容会展示在官网的“版本规划”中进行展示；
- 需求文档会邮件通知所有参与系统发布的同事。
2. 里程碑 Link to heading
由于前面所说的新版本不会要求计划内容都完成才发布，所以为了防止工作计划与实际工作产出相差过大，所以将每次系统版本发布做了阶段划分，也就是里程碑。举个例子来说，15.9 开发的阶段会划分为 15.8.1、15.8.2、 15.8.3、 15.8.4 等。
在每次里程碑开始之前，产品需要提前细化里程碑内的需求，在里程碑开始之前还未明确的需求，会被放入下个里程碑中。同样，在这个阶段，测试会根据产品需求编写测试用例。需求和测试用例都会经过一次评审。每个里程碑到达预定时间点之后，未完成的工作内容会按照优先级放入下个里程碑或者延后处理、放到其他里程碑中。
工具使用：
- 里程碑使用 github issues 中的 Milestone 工具来进行管理；
- 细化的需求文档以及需求变更会邮件通知所有参与系统发布的同事。
3. 工作周 Link to heading
每个里程碑由两个工作周组成。在每个工作周内，开发需要完成计划中的开发内容和上个工作周测试问题的修复工作，在每周结束的时候，开发对稳定的项目打 tag，并提交到 crp 平台进行打包、提供 changelog 供产品和测试在下个工作周进行验收。同样，在每个工作周内，产品和测试需要完成对上周开发内容的验收工作，保证在周三前完成功能验收、功能测试和 BUG 修复，周四时发布更新。
工具使用：
- 系统各个组件包版本控制、changlog 使用 crp 进行管理；
- 每周更新内容在 internal-discussion 中建相应里程碑发布任务的 issue 进行说明；
- 社区官网提供每次更新的更新注记。
目标 Link to heading
目前对滚动更新的期望主要有以下几点：
- 提升用户使用体验和满意度；
- 提升社区活跃度；
- 增加系统发布工作的灵活度；
- 发挥产品、开发和测试团队每个人的主观能动性；
- 最终整体上提高系统的稳定性和质量。
注：本文档将在 developer-center wiki 持续更新。