（转）Swift3.0发布过程

2016-09-14 本文已影响339人柠檬丶Lemon

本文转自：https://my.oschina.net/funnky/blog/684173
本文翻译自官网Blog: https://swift.org/blog/swift-3-0-release-process/
本文将阐述Swift 3.0的目标，发布过程以及预估进度.

Swift 3.0是一个与Swift 2.2源码不兼容的主发行版. 这个版本在语言和标准库上做出了根本性地改变. 对于Swift 3.0中所有实现变化的完整列表可在Swift evolution site查阅.

Swift 3.0同样也是第一个包含Swift包管理器的发行版. 尽管Swift包管理器尚处于开发早期，但其已支持对Swift包跨平台的开发和部署. Swift包管理器将同时支持Darwin及Linux.

对于Linux, Swift 3也会是第一个包含Swift核心库的发行版.

Swift 3.0预计会在16年下半年的某个时候发布. 除了在Swift.org发布, Swift 3.0也将集成在后续Xcode版本中推出.

开发者预览版
· Swift 3.0会有一系列的开发者预览版本 (例如“seeds”或者“betas”) 以期能提供合格的Swift 3构建版本. 这样做是为了提供给用户更稳定合格的可下载试用(并提交Bug)的Swift库，而不仅是抓取master
分支的最新快照.

· 各个开发者预览版之间的间隔很可能不一致, 大致上是每隔4-6个礼拜. 这会被要并入master
分支的变更大小和稳定下来所需时间长短所影响.

· Swift 3.0的最后一个开发者预览分支为“GM”.

· 进入开发者预览版本的内容将会被合适的发行管理人员来管理 (见下文).

Swift 3.0接收代码变更
分支
· master: Swift 3.0的开发全部在master
分支上. 所有在最后一个开发者预览分支创建前进入master
分支的变更都将会成为最终版本的一部分. 在这一点上master
分支会记录Swift未来版本的开发内容.

· swift-3.0-preview-<X>-branch**: 所有的开发者预览分支均从master
分支上切出. 提交到这些分支上的所有变更要通过pull request在持续集成系统上发起测试并提交. 各个仓库的发行管理员才可批准将此pull request合并入开发者预览分支.

· swift-3.0-branch: 最后一个开发者预览分支同样从master
分支切出，名叫swift-3.0-branch
. 这会是最终的“发行分支”.

可接受进入Swift 3.0变更的原则
· 随着Swift 3.0的汇聚，只会考虑和发布的核心目标相一致的变化.

· 语法变化将会逐一予以考虑.

· 所有语法和API的变化均记录在Swift Evolution.

· 准则 — 通过设立发行管理员 — 来严格审核接收随时间不断增加的变更. 同样的策略同样适用于开发者预览分支及其他迷你分支.

日程
· 首个开发者预览版分支swift-3.0-preview-1-branch
会在5月12号从master
分支切出. 会在4到6个礼拜后发布.

· 何时创建最后的开发者预览版分支swift-3.0-branch
还待定. 在日期确定后该计划会通过swift-dev传达，本文也会及时更新.

受影响的Git库
下列的Git库都将会有swift-3.0-preview--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

下列的Git库将只有swift-3.0-branch
分支而没有开发者预览分支, 因为它们已经被有效的集成了:
· swift-llvm
· swift-clang

发行管理员
发行版的管理全部由以下人员监管, 他们会严格控制能进入Swift 3.0发行版的变更提交，并决定集中发行:
· Ted Kremenek是Swift 3.0的总发行管理员.

· Kate Stone是负责swift-lldb的发行管理员.

如果你对发行管理过程有任何疑问，可以直接email给swift-dev或Ted Kremenek.

对于开发者预览版的Pull Request

所有要纳入开发者预览版分支的pull request必须要包含以下信息:
· 说明: 对于问题修复或改进实现的描述. 说明可以简短但一定要清楚明确.

· 作用: 评估会造成的影响和重要性. 比如, 该变更是否会造成语法变化, 等等.

· SR问题: 变更是否修复/实现了一个bugs.swift.org上的问题/改进.

· 风险: 采取该变更有何风险?

· 测试: 哪些具体的测试已完成或需要进一步验证变更可能会造成的影响?

被影响组件的一个或多个代码所有者必须要评审变更. 技术审查可由代码所有者授权或要求以其他方式证明适当或有效.
想要进入开发者预览分支的所有的变更****必须通过pull request提交并被发行管理员允许.