Swift 5.1 发布流程
这篇文章描述了 Swift 5.1 的目标、发布流程和预计时间表。
动机和目标
Swift 5.1 的首要目标是使该语言实现模块稳定性。
二进制兼容性
在 Apple 平台上，由于 ABI 现在已经稳定，Swift 5.1 与 Swift 5.0 二进制兼容，并且与 Swift 的未来版本二进制兼容。
在非 Apple 平台（如 Linux）上，ABI 尚未完全稳定，以便进行更多审查。对于基于 Linux 的新平台，这种审查尤其必要。
源码兼容性
与 Swift 5.0 一样，我们预计大多数使用 Swift 5.0 编译器构建的源代码都将可以使用 Swift 5.1 编译器进行编译。但是，Swift 5.1 中的错误修复可能会使其检测到以前未检测到的代码错误。
Swift 5.1 的快照
Swift 5.1 发布分支的可下载快照将定期发布，作为持续集成测试的一部分。
一旦 Swift 5.1 发布，除了快照之外，还将发布官方最终构建版本。
将更改纳入 Swift 5.1
Swift 5.0 的开发需要在整个收敛期间投入异常多的关注和精力，因为每个问题都必须评估其对永久 ABI 的影响。因此，Swift 5.1 的开发窗口比以前的版本明显缩短。这种更严格的时间限制是确保交付成熟且稳定的 5.1 版本所必需的，对于破坏性更改有更严格的截止日期。
swift-5.1-branch 分支包含将在 Swift 5.1 中发布的更改。该分支的管理方式如下
-
swift-5.1-branch分支已从master分支初始切出。 -
在最终分支日期之前，
master开发分支将定期合并到swift-5.1-branch分支中。 -
2019 年 3 月 18 日（最终分支）：
swift-5.1-branch分支将最后一次合并来自master分支的更改。在最终分支日期之后，将有一个“烘烤”期，在此期间只有经过挑选的关键修复程序才会进入发布版本（通过拉取请求）。
下表指出了此计划的一些值得注意的例外情况。每个例外情况都将每天从 master 分支合并到 swift-5.1-branch 分支中。每个例外情况的最终更改截止日期将延长至 3 月 18 日之后，并将稍后公布。
| 项目 | 截止日期 |
|---|---|
| indexstore-db | 待公布 |
| sourcekit-lsp | 待公布 |
| swift-corelibs-foundation | 待公布 |
| swift-corelibs-libdispatch | 待公布 |
| swift-corelibs-xctest | 待公布 |
| swift-llbuild | 2019 年 4 月 10 日 |
| swift-package-manager | 2019 年 4 月 10 日 |
| swift-stress-tester | 待公布 |
| swift | 2019 年 3 月 18 日 |
将更改纳入 Swift 5.1 的原则
-
Swift 5.1 的所有语言和 API 更改都将通过 Swift 演进流程。演进提案应力争在分支日期前完成，以增加它们对 Swift 5.1 发布版本的影响。例外情况将根据具体情况考虑，特别是如果它们与发布的**核心目标**相关联。
-
其他更改（例如，错误修复、诊断改进、SourceKit 接口改进）将根据其风险和影响被接受。
-
如果低风险的测试调整有助于发布版本的资格认证，那么这些调整也将在发布分支的后期被接受。
-
随着发布版本的收敛，接受更改的标准将变得越来越严格。
受影响的仓库
以下仓库将有一个 swift-5.1-branch 分支，以跟踪作为 Swift 5.1 发布版本一部分的源代码
- indexstore-db
- sourcekit-lsp
- 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-stress-tester
- swift-syntax
- swift-xcode-playground-support
发布经理
发布版本的总体管理将由以下人员监督，他们将在 Swift 5.1 发布版本收敛时宣布何时对更改实施更严格的控制
-
Ted Kremenek 是 Swift 5.1 的总体发布经理。
-
Duncan Exon Smith 是 swift-llvm、swift-clang、swift-compiler-rt、swift-clang-tools-extra 和 swift-libcxx 的发布经理。
-
Fred Riss 是 swift-lldb 的发布经理。
-
Ben Cohen 是 Swift 标准库的发布经理。
-
Tony Parker 是 swift-corelibs-foundation 的发布经理。
-
Brian Croom 是 swift-corelibs-xctest 的发布经理。
-
Rick Ballard 是 swift-package-manager 的发布经理。
-
Daniel Dunbar 是 swift-llbuild 的发布经理。
-
Argyrios Kyrtzidis 是 sourcekit-lsp、indexstore-db 和 swift-stress-tester 的发布经理。
如果您对发布管理流程有任何疑问，请随时在开发论坛上发帖，或直接联系 Ted Kremenek。
发布分支的拉取请求
为了使拉取请求在最终从 master 分支重新分支后被考虑包含在发布分支中，它必须包含以下信息
-
说明：对正在修复的问题或正在进行的增强功能的描述。这可以简短，但应该清楚。
-
范围：对更改的影响/重要性的评估。例如，更改是否是破坏源码的语言更改等。
-
SR Issue：如果更改修复/实现了 bugs.swift.org 上的问题/增强功能，则为 SR。
-
风险：接受此更改对发布版本有何（具体）风险？
-
测试：已经完成或需要完成哪些具体测试，以进一步验证此更改的任何影响？
-
审核人：受影响组件的一名或多名代码所有者应审核更改。技术审核可以由代码所有者委托或根据需要或有用的方式请求。
进入 swift-5.1-branch 分支的所有更改（自动从 master 分支合并的更改除外）必须通过拉取请求，并且必须由相应的发布经理接受。