Swift 2.2 发布流程

2016年1月5日

Ted Kremenek

这篇文章描述了 Swift 2.2 的目标、发布流程和预计时间表。

Swift 2.2 是 Swift 开源后的第一个正式版本。它将是一个与 Swift 2.1 大部分源码兼容的版本，包含大量核心改进（例如，缺陷修复、诊断增强、更快的生成代码），但语言本身没有太多明显的更改。它旨在成为 Swift 2 和 Swift 3 之间的中间点，Swift 3 将包含对语言和标准库更具颠覆性的更改。

Linux 上的 Swift 将包含在此版本中。然而，它仍然相对较新，并且存在已知的注意事项。Swift 2.2 将不包含 Swift 核心库，但将包含 LLDB 和 REPL。

Swift 包管理器 仍处于早期开发阶段，将不包含在此版本中。

除了 发布之外，Swift 2.2 还将在未来版本的 Xcode 中发布。

物流

受影响的仓库

以下仓库将拥有一个 swift-2.2-branch 分支，以跟踪作为 Swift 2.2 发布一部分的源代码

• swift
• swift-llvm
• swift-clang
• swift-lldb
• swift-cmark

时间表

• Swift 2.2 将于 2016 年 1 月 13 日 从 master 分支分叉。1 月 13 日之后，master 分支将主要跟踪 Swift 3 的开发。这特别适用于 swift、swift-lldb 和 swift-cmark 仓库。

• swift-llvm 和 swift-clang 仓库的 swift-2.2-branch 分支创建得更早，大约在 LLVM 修订版 252576，以便有更长的时间来稳定底层的 LLVM 平台。这些仓库将不会从 master 分支重新合并。

• Swift 2.2 的最终发布日期待定。目的是让 Swift 2.2 经历一个收敛期，并可能在 2016 年 3 月至 5 月之间的某个时间发布。

• Swift 2.2 发布分支的二进制构建版本将与 Swift master 开发分支的快照一起提供。

• Swift 3 将遵循与 Swift 2.2 类似的 branching 流程，并将在未来日期公布。

将更改纳入 Swift 2.2

• 在 1 月 13 日之前，所有进入 Swift master 分支的更改，根据定义，都将成为 Swift 2.2 的一部分。

• 此后，在分支之后，Swift 2.2 只会考虑那些使其更源码兼容 Swift 2.1 的语言/API 更改，或者代码的迁移警告，这些代码在 Swift 3 中将成为构建错误。除非有非常好的理由，否则新的特性/扩展将不被接受。

• 随着版本发布的收敛，接受更改的标准（由发布经理设定）将变得越来越严格。

• 对于没有直接提交权限的贡献者，可以通过 pull request 发起对 swift-2.2-branch 的贡献。Pull request 通常应用于拉取已在 master 分支中的更改，除非这些更改特定于 Swift 2.2 并且不会包含在 Swift 3 中。例如，错误修复应首先在 master 分支中落地，然后再拉取到 swift-2.2-branch。

• 具有直接提交权限的核心贡献者将能够在各自代码所有者或发布经理的指导下，直接 cherry-pick 或以其他方式将更改应用于 swift-2.2-branch，直到时间表中的某个点，该分支将受到严格的变更控制。一旦 swift-2.2-branch 受到更严格的变更管理，将向相关的组件开发邮件列表（例如，swift-dev）发布公告。届时，所有更改都必须通过 pull request 的提名流程。

发布管理

发布的总体管理将由以下个人监督，他们将在 Swift 2.2 版本收敛时宣布何时对更改进行更严格的控制

• Ted Kremenek 是 Swift 2.2 的总体发布经理。

• Bob Wilson 是 Swift 2.2 的 LLVM 和 Clang 组件的发布经理。

• Kate Stone 是 Swift 2.2 的 LLDB 组件的发布经理。

如有关于发布管理流程的任何问题，请随时发送电子邮件至 swift-dev 或直接联系 Ted。

注意：Swift 邮件列表已关闭、存档，并被 Swift 论坛 取代。请参阅此处的公告。

Pull Requests

所有提名更改以包含在 swift-2.2-branch 中的 pull request 都应包含以下信息

• 解释：对正在修复的问题或正在进行的增强功能的描述。这可以简短，但应该清晰。

• 范围：对更改的影响/重要性的评估。例如，更改是否是破坏源码的语言更改等。

• SR 问题：SR（如果更改修复/实现 bugs.swift.org 上的问题/增强功能）。

• 风险：接受此更改对发布有什么（特定）风险？

• 测试：已完成或需要完成哪些具体测试，以进一步验证此更改的任何影响？

受影响组件的一个或多个代码所有者应审查更改。技术审查可以由代码所有者委派，或者根据认为适当或有用的方式请求。

在 swift-2.2-branch 进入限制性更改控制之前（由发布经理宣布），代码所有者在经过上述技术审查后，可以直接接受 pull request。一旦限制性更改控制到位，只有发布经理才能接受进入 swift-2.2-branch 的 pull request。