この記事の要点
- Swift 4.2 の目標・リリースプロセス・想定スケジュールを示した記事です。
- Swift 4.2 は、Swift 5 での ABI 安定化に向けた通過点(waypoint)と位置づけられます。性能関連を中心とした多数の内部的(under-the-hood)な ABI 変更を段階的に導入し、最終的な ABI に固定される前にユーザーからのフィードバックを得る期間を設けることが狙いです。
- Swift 4.2 は Swift 4.1 などこれまでのリリースとはバイナリ互換ではありません。一方でソース互換性は高く、Swift 4.0 コンパイラ(Swift 3 互換モードを使うものを含む)でビルドできたソースの大半はそのままビルドできる見込みです。
- 多数のバグ修正に加え、コンパイル時間の性能改善にも重点を置きます。
- これまでのリリースと同様、リリースブランチのスナップショットを定期的に提供します。
masterからswift-4.2-branchへの最終マージは 2018 年 4 月 20 日で、それ以降は厳選された重要な修正のみがリリースに入ります。
リリース計画の概要
Swift 4.2 の位置づけ
Swift 4.2 は、Swift 5 で 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 リリースブランチのダウンロード可能なスナップショットは、継続的インテグレーション(CI)テストの一部として定期的に公開されます。Swift 4.2 のリリース後は、スナップショットに加えて公式の最終ビルドも公開されます。
スケジュールとブランチ運用
swift-4.2-branch には Swift 4.2 でリリースされる変更が含まれ、次のように運用されます。
- 直近:
swift-4.2-branchがmasterから最初に分岐されます。 - 最終ブランチ作成日までおおよそ 2 週間ごとに、
masterがswift-4.2-branchにマージされます。 - 2018 年 4 月 20 日(最終ブランチ作成):
masterからswift-4.2-branchへの最後のマージが行われます。それ以降は「bake(熟成)」期間として、厳選された重要な修正のみがプルリクエストを通じてリリースに入ります。
この計画には 4 つの注目すべき例外があります。swift-package-manager・swift-llbuild・swift-corelibs-foundation・swift-corelibs-libdispatch は master から swift-4.2-branch へ毎日マージされ、これらの変更の最終締め切りは 4 月 20 日より後になるとされました。一部のプロジェクトの締め切りは次のとおりです。
| プロジェクト | 締め切り |
|---|---|
| swift | 2018 年 4 月 20 日 |
| swift-package-manager | 2018 年 6 月 28 日 |
| swift-llbuild | 2018 年 7 月 5 日 |
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.2-branch を持ちます。
リリースマネージャ
リリース全体は次の担当者が統括し、リリースが収束するにつれて変更管理が厳格化される時点を告知します。
- 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 のリリースマネージャ
なお、当時案内されていた開発フォーラム(development forum)は現在の Swift Forums に置き換えられています。リリース管理プロセスについての質問は、フォーラムへの投稿や Ted Kremenek への連絡が案内されました。
参加・確認すべきポイント
Swift 4.2 に変更を取り込む流れ
- すべての言語・API の変更は Swift Evolution プロセスを経ます。どの変更がリリースのスコープに入るかの基準もそこに文書化されます。
- それ以外の変更(バグ修正、診断の改善、SourceKit のインターフェイス改善など)は、リスクと影響に基づいて受け入れられます。
- リリースの品質確認に役立つ場合は、リスクの低いテストの微調整もリリースブランチに遅い段階で受け入れられます。
- リリースが収束するにつれて、取り込み基準は徐々に厳しくなります。
プルリクエストに添える情報
リリースブランチへの取り込みを提案するプルリクエストには、次の情報を含めます。
- Explanation(説明): 修正する問題や行う拡張の説明。簡潔でよいが明確であること。
- Scope(影響範囲): 変更の影響・重要度の評価。たとえばソース互換性を壊す言語変更かどうかなど。
- SR Issue: 対応する bugs.swift.org の SR 番号(該当する場合)。
- Risk(リスク): その変更を取り込むことでリリースに生じる具体的なリスク。
- Testing(テスト): 影響を検証するために実施済み、または必要なテスト。
影響を受けるコンポーネントのコードオーナーがレビューを行います。技術レビューはコードオーナーが委任することも、必要に応じて依頼することもできます。master から自動的にマージされる変更を除き、swift-4.2-branch に入るすべての変更は、対応するリリースマネージャが受け入れるプルリクエストを経る必要があります。