Swift 3.0 发布流程
本文档描述了 Swift 3.0 的目标、发布流程和预计时间表。
Swift 3.0 是一个主要版本,不与 Swift 2.2 源码兼容。它包含了对语言和 Swift 标准库的根本性更改。关于 Swift 3.0 已实现更改的完整列表,请访问 Swift 演化网站。
Swift 3.0 也是首个包含 Swift 包管理器 的版本。虽然 Swift 包管理器仍处于早期开发阶段,但它支持跨平台 Swift 包的开发和分发。Swift 包管理器将在 Darwin 和 Linux 上可用。
对于 Linux,Swift 3 也将是首个包含 Swift 核心库 的版本。
Swift 3.0 预计将于 2016 年底发布。除了在 上发布外,Swift 3.0 还将在未来版本的 Xcode 中发布。
开发者预览版
-
Swift 3.0 将有一系列的开发者预览版(即 “seeds” 或 “betas”),提供合格且已收敛的 Swift 3 构建版本。目标是为用户提供更稳定和合格的 Swift 二进制文件,以便他们可以 下载 并试用(并提交错误报告),而不是仅仅获取
master的最新快照。 -
开发者预览版的发布节奏可能不规律,但大概每 4-6 周一次。发布节奏将部分取决于进入
master的变更量以及稳定开发者预览分支所需的时间。 -
Swift 3.0 将从最后一个开发者预览分支声明为 “GM”。
-
进入开发者预览版的内容将由相应的发布经理管理(见下文)。
将更改纳入 Swift 3.0
分支
-
master:Swift 3.0 的开发在
master分支上进行。在创建最后一个开发者预览分支之前,所有进入master的更改都将成为最终 Swift 3.0 版本的一部分。在那之后,master分支将跟踪未来 Swift 版本的开发。 -
swift-3.0-preview-<X>-branch:开发者预览分支将从
master分支创建。对这些分支的所有更改都需要通过拉取请求提交,以启动持续集成测试。给定仓库的发布经理批准将拉取请求合并到开发者预览分支中。 -
swift-3.0-branch:从
master创建的最后一个开发者预览分支将被称为swift-3.0-branch。这将是最终的 “发布分支”。
关于将更改纳入 Swift 3.0 的理念
-
随着 Swift 3.0 的收敛,只会考虑符合该版本核心目标的更改。
-
对于语言的源码破坏性更改,将根据具体情况进行考虑。
-
Swift 3.0 的所有语言和 API 更改都将通过 Swift 演化 流程。
-
随着版本收敛,发布经理设定的接受更改的标准将随着时间的推移变得越来越严格。同样的政策适用于开发者预览分支,它们本质上是迷你版本。
时间表
-
第一个开发者预览分支
swift-3.0-preview-1-branch将于 5 月 12 日 从master分支创建。它将在 4-6 周后发布。 -
创建最后一个开发者预览分支 —
swift-3.0-branch— 的日期尚未确定。一旦日期确定,计划将在 swift-dev 邮件列表和更新本文档中进行沟通。
受影响的仓库
以下仓库将拥有 swift-3.0-preview-<X>-branch/swift-3.0-branch 分支来跟踪作为 Swift 3.0 版本一部分的源码
- swift
- swift-lldb
- swift-cmark
- swift-llbuild
- swift-package-manager
- swift-corelibs-libdispatch
- swift-corelibs-foundation
- swift-corelibs-xctest
以下仓库将仅拥有 swift-3.0-branch 分支,而不是开发者预览分支,因为它们实际上已经收敛
发布经理
版本的总体管理将由以下个人监督,他们将在 Swift 3.0 版本收敛时宣布何时开始对更改实施更严格的控制
-
Ted Kremenek 是 Swift 3.0 的总体发布经理。
-
Frédéric Riss 是 swift-llvm 和 swift-clang 的发布经理。
-
Kate Stone 是 swift-lldb 的发布经理。
-
Tony Parker 是 swift-corelibs-foundation 的发布经理。
-
Daniel Steffen 是 swift-corelibs-libdispatch 的发布经理。
-
Mike Ferris 是 swift-corelibs-xctest 的发布经理。
-
Rick Ballard 是 swift-package-manager 的发布经理。
如果您对发布管理流程有任何疑问,请随时发送电子邮件至 swift-dev 邮件列表或直接联系 Ted Kremenek。
开发者预览版的拉取请求
所有提名更改以包含在开发者预览分支中的拉取请求都应包含以下信息
-
解释:对正在修复的问题或正在进行的增强的描述。可以简短,但应清晰明了。
-
范围:对更改的影响/重要性的评估。例如,更改是否为源码破坏性语言更改等。
-
SR 问题:SR(如果更改修复/实现 bugs.swift.org 上的问题/增强功能)。
-
风险:接受此更改对版本发布的(具体)风险是什么?
-
测试:已完成或需要完成哪些具体测试,以进一步验证此更改的任何影响?
受影响组件的一个或多个 代码所有者 应审查更改。技术审查可以由代码所有者委托,或根据需要或有益的其他方式请求。
所有进入开发者预览分支的更改都必须通过拉取请求,并由相应的发布经理接受。