Swift 4 发布流程

2017 年 2 月 16 日

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

Swift 4 是一个主要版本，计划于 2017 年秋季完成。它的核心是为 Swift 3 代码提供源代码稳定性，同时实现语言中实现二进制稳定性所需的基本功能。它将包含对核心语言和标准库的重大增强，尤其是在泛型系统和 String 类型的改造方面。更多详细信息可以在 Swift Evolution 页面上找到。

源代码兼容性

Swift 4 编译器将提供两种语言模式：-swift-version 3 和 -swift-version 4。

Swift 版本 3 模式

第一种模式 -swift-version 3 是现有代码的默认模式。在这种模式下，一个强烈的目标是，绝大多数使用 Swift 3.1 编译器构建的源代码能够继续使用 Swift 4 编译器构建。例外情况是编译器中的错误修复，这些修复会导致编译器拒绝原本就不应该接受的代码。这些情况在实践中应该相对罕见。

如果您遇到 Swift 4 编译器意外拒绝先前使用 Swift 3.1 编译器编译的代码的情况，请提交错误报告。

Swift 版本 4 模式

第二种模式 -swift-version 4 是一种提供此版本中新的和颠覆性更改的模式。尤其重要的是 String API 的彻底改造，其中的一个关键重点是提高 API 的人体工程学和性能。这些更改是源代码破坏性的，因此将需要现有代码迁移到使用新的 API。

值得注意的是，从代码迁移的角度来看，Swift 3 和 Swift 4 代码之间的差异预计将比从 Swift 2.2 到 Swift 3 的跳跃要小得多。

混合使用不同语言模式的代码

预期的设计是，包含多个 Swift 模块的项目（例如，具有多个 Swift 目标的 Xcode 项目）将能够在每个模块（目标）级别采用特定的 Swift 语言模式，并且它们可以在同一个编译后的二进制文件中自由交互。请注意，只有当目标使用相同的编译器编译时，这种互操作性才会在二进制级别存在。

以下是一些这种互操作性实现的示例

在 Xcode 中，应用程序目标可以用 Swift 4（即 -swift-version 4）编写，但项目可以有一个单独的框架目标，供应用程序使用，该框架目标用 Swift 3（即 -swift-version 3）编写。
用 Swift 4（即 -swift-version 4）编写的 Swift 软件包应该能够使用用 Swift 3 编写的现有软件包，而无需软件包将其源代码更新到 Swift 4。

总的来说，这个方案将允许现有的 Swift 3 代码更逐步地迁移到 Swift 4（例如，一次迁移一个目标或软件包）。

有关 Swift 版本源代码兼容性意图的更详细描述，请参阅 swift-evolution 邮件列表上的主题。

Swift 4 的快照

与 Swift 3.1 的情况一样，对于 Swift 4，将有每日可下载的发布分支快照。快照将作为持续集成测试的一部分生成。因此，可下载快照的节奏将更加频繁和精细。如果测试通过，快照将每天发布。

一旦 Swift 4 发布，除了快照之外，还将发布官方最终版本。

将更改纳入 Swift 4

所有更改目前都进入主线开发（即 master 分支），直到发布经理宣布最终分支日期，这很可能在 2017 年初夏的某个时候。在那之后，将有一个“烘烤”期，在此期间，只有精选的关键修复才会进入 swift-4.0-branch，而 master 将继续进行下一个版本的开发。

分支

master：除了 swift-llvm、swift-clang 和 swift-lldb 存储库（请参阅受影响的存储库）之外，Swift 4 的开发在 master 中进行。在最终分支日期之前，进入 master 的所有更改都将成为最终 Swift 4 版本的一部分。届时，master 将跟踪下一个版本的开发。
swift-4.0-branch：Swift 4 的发布管理在 swift-4.0-branch 上进行。所有 Swift 4 快照都从此分支构建，Swift 4 GM 也将从此分支构建。

在操作上，master 将大约每两周定期合并到 swift-4.0-branch 中，直到最终分支日期。这两周的窗口在 master 上的热开发和精心策划的发布分支之间提供了一个缓冲。更改可以在 master 的合并之间通过拉取请求 (pull request) 挑选到 swift-4.0-branch 中。

此计划的一个显著例外是 swift-package-manager，它将每天从 master 合并到 swift-4.0-branch。

将更改纳入 Swift 4 的理念

在 -swift-version 3 模式下，与 Swift 3.1 的源代码兼容性是首要任务。
随着 Swift 4 的收敛，只会考虑符合此版本核心目标的更改。
Swift 4 的所有语言和 API 更改都将通过 Swift Evolution 流程，其中记录了此版本范围内的更改标准。
随着版本的收敛，将更改拉入版本 4 的标准将变得越来越严格。

受影响的存储库

以下存储库将具有 swift-4.0-branch 分支，以跟踪作为 Swift 4 发布一部分的源代码

请注意，swift-llvm、swift-clang 和 swift-lldb 存储库已从 master 分支 swift-4.0-branch，并且不会再次分支。

发布经理

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

Ted Kremenek 是 Swift 4 的总体发布经理。
Frédéric Riss 是 swift-llvm 和 swift-clang 的发布经理。
Ben Cohen 是 Swift 标准库的发布经理。
Tony Parker 是 swift-corelibs-foundation 的发布经理。
Daniel Steffen 是 swift-corelibs-libdispatch 的发布经理。
Brian Croom 是 swift-corelibs-xctest 的发布经理。
Rick Ballard 是 swift-package-manager 的发布经理。

如果您对发布管理流程有任何疑问，请随时发送电子邮件至 swift-dev 或直接联系 Ted Kremenek。

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

发布分支的拉取请求

所有提名更改以包含在发布分支中的拉取请求都应包含以下信息

解释：对正在修复的问题或正在进行的增强的描述。这可以简短，但应该清晰。
范围：对更改的影响/重要性的评估。例如，更改是否是源代码破坏性的语言更改等。
SR 问题：SR（如果更改修复/实现 bugs.swift.org 上的问题/增强）。
风险：进行此更改对发布有什么（具体）风险？
测试：已完成或需要完成哪些具体测试，以进一步验证此更改的任何影响？

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

进入 swift-4.0-branch 的所有更改（自动从 master 合并的更改除外）必须通过拉取请求，这些拉取请求必须由相应的发布经理接受。