Swift Digest
この記事の要点
- Swift 4 の目標・リリースプロセス・想定スケジュールを示した記事です。Swift 4 は 2017 年秋のリリースを目指すメジャーリリースとされました。
- Swift 4 は、Swift 3 のコードに対するソース安定性（source stability）を提供しつつ、言語のバイナリ安定性（binary stability）の達成に必要な機能を実装することを軸とします。ジェネリクスシステムの強化や
String型の刷新など、中核言語と標準ライブラリへの大きな拡張を含みます。 - Swift 4 コンパイラは
-swift-version 3と-swift-version 4の 2 つの言語モードを提供します。既存コードは-swift-version 3のままビルドでき、新しく破壊的な変更は-swift-version 4で導入されます。 - 言語モードはモジュール（ターゲット）単位で選べ、異なるモードのモジュールを同じバイナリ内で混在させられます。これにより既存の Swift 3 コードをターゲットやパッケージ単位で段階的に Swift 4 へ移行できます。
- これまでのリリースと同様、リリースブランチの日次スナップショットを提供します。
masterへの変更が Swift 4 に入るのは最終ブランチ作成日まで（2017 年初夏ごろの見込み）で、それ以降は厳選された重要な修正のみがswift-4.0-branchに入ります。
リリース計画の概要
Swift 4 の位置づけ
Swift 4 は 2017 年秋の完成を目指すメジャーリリースです。Swift 3 のコードに対するソース安定性を提供しながら、言語のバイナリ安定性を達成するために必要な中核的な機能を実装することを軸とします。中核言語と標準ライブラリには大きな拡張が入り、特にジェネリクスシステムの強化と String 型の刷新が含まれます。Swift 4 向けに進められる作業は Swift Evolution のページで確認できます。
2 つの言語モード
Swift 4 コンパイラは -swift-version 3 と -swift-version 4 の 2 つの言語モードを提供します。
-swift-version 3モード: 既存コードのデフォルトです。Swift 3.1 コンパイラでビルドできたソースの大半が Swift 4 コンパイラでもビルドできることを強い目標とします。例外は、本来受け入れるべきでなかったコードを拒否するようになるコンパイラのバグ修正に限られ、実際にそうしたケースは比較的まれとされました。Swift 3.1 ではビルドできたのに Swift 4 で予期せず拒否されるコードに遭遇した場合は、bugs.swift.org にバグ報告することが推奨されました。-swift-version 4モード: このリリースの新しく破壊的な変更が利用できるモードです。特に重要なのがStringAPI の刷新で、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 4 に更新していない既存の Swift 3 パッケージをそのまま利用する。
これにより、既存の Swift 3 コードをターゲットやパッケージ単位で、より緩やかに Swift 4 へ移行できます。
スナップショットによる提供
Swift 3.1 と同様、Swift 4 でもリリースブランチの日次スナップショットを提供します。スナップショットは継続的インテグレーション（CI）テストの一部として生成され、テストが通っていれば毎日公開されるため、より高頻度かつ細かい粒度になります。Swift 4 のリリース後は、スナップショットに加えて公式の最終ビルドも公開されます。
スケジュールとブランチ運用
master（メインライン開発）に入る変更は、リリースマネージャが最終ブランチ作成日を告知するまで Swift 4 に入ります。最終ブランチ作成日は 2017 年初夏ごろの見込みとされ、それ以降は「bake（熟成）」期間として、厳選された重要な修正のみが 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（Golden Master）になります。
運用上は、最終ブランチ作成日までおおよそ 2 週間ごとに master が swift-4.0-branch に定期マージされます。2 週間の間隔は、活発に開発される master と、整理されたリリースブランチとの間のバッファになります。マージとマージの間には、プルリクエストによる cherry-pick で swift-4.0-branch に変更を取り込むこともできます。この計画の例外は swift-package-manager で、こちらは master から swift-4.0-branch へ毎日マージされます。
Swift 4 のブランチ運用は複数のリポジトリにまたがり、swift・swift-lldb・swift-cmark・swift-llbuild・swift-package-manager・swift-corelibs-libdispatch・swift-corelibs-foundation・swift-corelibs-xctest・swift-llvm・swift-clang が swift-4.0-branch を持ちます。なお swift-llvm・swift-clang・swift-lldb は既に master から swift-4.0-branch を分岐済みで、再分岐はしません。
リリースマネージャ
リリース全体は次の担当者が統括し、リリースが収束するにつれて変更管理が厳格化される時点を告知します。
- 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 メーリングリストは現在は閉鎖・アーカイブされ、Swift Forums に置き換えられています。
参加・確認すべきポイント
Swift 4 に変更を取り込む流れ
-swift-version 3モードでの Swift 3.1 とのソース互換性が最優先されます。- Swift 4 が収束するにつれて、リリースの中核的な目標に沿う変更だけが検討されるようになります。
- すべての言語・API の変更は Swift Evolution プロセスを経ます。どの変更がリリースのスコープに入るかの基準もそこに文書化されます。
- リリースが収束するにつれて、Swift 4 への取り込み基準は徐々に厳しくなります。
プルリクエストに添える情報
リリースブランチへの取り込みを提案するプルリクエストには、次の情報を含めます。
- Explanation（説明）: 修正する問題や行う拡張の説明。簡潔でよいが明確であること。
- Scope（影響範囲）: 変更の影響・重要度の評価。たとえばソース互換性を壊す言語変更かどうかなど。
- SR Issue: 対応する bugs.swift.org の SR 番号（該当する場合）。
- Risk（リスク）: その変更を取り込むことでリリースに生じる具体的なリスク。
- Testing（テスト）: 影響を検証するために実施済み、または必要なテスト。
影響を受けるコンポーネントのコードオーナーがレビューを行います。技術レビューはコードオーナーが委任することも、必要に応じて依頼することもできます。master から自動的にマージされる変更を除き、swift-4.0-branch に入るすべての変更は、対応するリリースマネージャが受け入れるプルリクエストを経る必要があります。