7.7 发布时间表

Deis 项目一些最伟大的资产就是速度和敏捷性。DEIS 初始开发期间迅速且相对容易地改变。

Deis 现在利用这些优势转化为常规动力，公开发布的节奏。从 v1.0.0 开始，Deis 项目将每月发布一个小版本，所需的补丁版本。这个项目将使用 GitHub milestones 来传达内容和大小版本的时间线。

Deis 发布不是基于特性的，在那个日期并不与特定的功能相关。如果一个特性在发布日期之前合并，它将包含在下个小或者是大的发行版中。

Deis 的 master git 分支一直保持工作。只有经过深思熟虑考虑公开发布的变更才会被合并，并从 master 分支发布。

语义版本

Deis 发布符合语义版本，“公共 API”广义的定义为：

• deis-controller 的 REST API
• etcd 的键值是公开记录的
• deis 和 deisctl 的命令和选项
• 必需的 Makefile 目标
• 在 contrib/ 提供脚本

Deis 的用户可以非常有信心的升级一个补丁或者是一个小版本而不用以一个无法向后兼容的方式改变他们 items 的行为。

补丁版本

Deis 的补丁版本包含向后兼容的 bug 修复。升级到这个版本是安全的并且可以一次完成。

在 Deis 中，在有了两个批准评论后，向后兼容的 bug 修复是被可以在任何时候合并进 master 分支的。

补丁版本只要被需要就可以被创建，基于一个或多个 bug 修复被合并的优先级。如果时间和严重程度是至关重要的，一个个人的维护者可以在没有取得其他人共识的前提下创建一个补丁版本。补丁版本是从前一个被 cherry-picking 从 master 分支指定的 bug 修复版本被创建的。然后申请和推送新的版本 tag。

小版本

Deis 小版本引入的功能是向后兼容的。升级到该版本是安全的并且一次完成的。

在 Deis 中，在有了两个批准评论后，向后兼容的功能性变更 是被可以在任何时候合并进 master 分支的，并且之后 PR 已经被分配到一个里程碑来跟踪这个小版本。

最好在一个小版本中合并几个向后兼容的功能性变更。

Deis 项目将使用 GitHub 里程碑来传达内容和小版本计划时间。当前的项目维护者在星期四下午相互见面来分配 pull requests 到里程碑。

Deis 项目将在每个月的第一个星期二发布平台的小版本。为了适应假期或是不寻常的情况，目标日会被轮换。如果项目维护者同意了，一个额外的小版本或许会在计划版本产生。代码冻结和进一步的验收测试开始于目标发行版之前的星期四。

一个小版本可能会被一个主版本取代。

主版本

Deis 项目的主版本包含不兼容的 API 变更。升级到这个版本涉及到备份和恢复过程。Deis 的定制集成或许需要更新。

Deis 不兼容的变更是非常谨慎的通过所有维护人员的协商来合并进 master 分支。额外的需要两个批准评论。pull request 必须被分配到该发行版的计划性里程碑中，当发布活动和开始测试时，它会被合并。

Deis 项目将使用 GitHub 里程碑来传达内容和主版本的计划时间。