Swift 4.2 发布流程

2018年2月28日

Ted Kremenek

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

动机和目标

Swift 4.2 旨在成为在 Swift 5 中实现 ABI 稳定性的一个中间步骤。

Swift 4.2 将包含许多幕后的 ABI 更改，作为稳定 Swift ABI 工作的一部分。 逐步推出 ABI 更改（其中许多与性能相关）非常有价值，这为用户评估这些更改提供了充足的时间，然后再将其锁定到最终 ABI 中。

Swift 4.2 还将包含许多错误修复，并以专注于编译时性能的某些改进为目标。

二进制兼容性

Swift 4.2 与之前的 Swift 版本不二进制兼容。

源码兼容性

与 Swift 4.1 一样，绝大多数使用 Swift 4.0 编译器构建的源代码（包括那些使用 Swift 3 兼容模式的源代码）应该可以使用 Swift 4.2 编译器编译。

在某些特殊情况下，这不能绝对保证。 这包括修复编译器中的不正确行为，或使用泛型时遇到的极端情况，这些情况现在已通过引入期待已久的泛型功能得到解决。 然而，期望是大多数项目将继续构建，而无需更改源代码。

Swift 4.2 的快照

Swift 4.2 发布分支的可下载快照将定期发布，作为持续集成测试的一部分。

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

将更改纳入 Swift 4.2

swift-4.2-branch 分支包含将在 Swift 4.2 中发布的更改。 该分支的管理方式如下

• 即将进行：swift-4.2-branch 将最初从 master 分支切出。
• 大约每两周，master 分支将被合并到 swift-4.2-branch 分支中，直到最终分支日期。
• 2018 年 4 月 20 日（最终分支）：swift-4.2-branch 分支将最后一次合并来自 master 分支的更改。 在最终分支日期之后，将有一个“烘烤”期，在此期间，只有精选的关键修复程序才会进入发布版本（通过拉取请求）。

此计划的四个值得注意的例外是 swift-package-manager、swift-llbuild、swift-corelibs-foundation 和 swift-corelibs-libdispatch，它们将每天从 master 分支合并到 swift-4.2-branch 分支，并且其最终更改截止日期将延长至 4 月 20 日之后，具体时间将稍后公布。

将更改纳入 Swift 4.2 的理念

• Swift 4.2 的所有语言和 API 更改都将通过 Swift Evolution 流程，其中记录了该版本范围内的更改标准。

• 其他更改（例如，错误修复、诊断改进、SourceKit 接口改进）将根据其风险和影响被接受。

• 如果低风险的测试调整有助于版本的限定，那么即使在发布分支的后期，这些调整也会被接受。

• 随着发布版本的收敛，接受更改的标准将变得越来越严格。

受影响的存储库

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

• swift
• swift-clang
• swift-cmark
• swift-compiler-rt
• swift-corelibs-foundation
• swift-corelibs-libdispatch
• swift-corelibs-xctest
• swift-integration-tests
• swift-llbuild
• swift-lldb
• swift-llvm
• swift-package-manager
• swift-xcode-playground-support

发布经理

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

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

• Duncan Exon Smith 是 swift-llvm、swift-clang 和 swift-compiler-rt 的发布经理。

• Ben Cohen 是 Swift 标准库的发布经理。

• Tony Parker 是 swift-corelibs-foundation 的发布经理。

• Daniel Steffen 是 swift-corelibs-libdispatch 的发布经理。

• Brian Croom 是 swift-corelibs-xctest 的发布经理。

• Rick Ballard 是 swift-package-manager 的发布经理。

• Daniel Dunbar 是 swift-llbuild 的发布经理。

如果您对发布管理流程有任何疑问，请随时在开发论坛上发帖，或直接联系 Ted Kremenek。

发布分支的拉取请求

为了使拉取请求被考虑包含在发布分支中，它必须包含以下信息

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

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

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

• 风险：接受此更改对发布版本有何（具体）风险？

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

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

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