バージョン管理ポリシー

Spark 1.0.0 以降、Spark プロジェクトは、いくつかの例外を除き、セマンティックバージョニングガイドラインに従います。これらの小さな違いは、Spark がマルチモジュールプロジェクトであるという性質によるものです。

Spark のバージョン

各 Spark リリースは、[MAJOR].[FEATURE].[MAINTENANCE] の形式でバージョン管理されます。

• MAJOR: 同じメジャーバージョン番号を持つすべてのリリースは、API 互換性があります。メジャーバージョン番号は長期間安定します。たとえば、1.X.Y は 1 年以上続く可能性があります。
• FEATURE: 機能リリースには、通常、新機能、改善、バグ修正が含まれます。各機能リリースには、新しいパッチをマージできるマージウィンドウ、修正のみをマージできる QA ウィンドウ、その後、リリース候補に対する投票が行われる最終期間があります。これらのウィンドウは、前の機能リリース直後に発表され、十分な時間が与えられます。将来的には、リリースプロセス全体をより規則的（Ubuntu のような）にする可能性があります。
• MAINTENANCE: メンテナンスリリースはより頻繁に発生し、導入された特定のパッチ（バグ修正など）とその緊急性によって異なります。一般的に、これらのリリースはバグの修正を目的としています。ただし、上位レベルのライブラリは、既存のコードパスから完全に累積的で分離されている限り、新しいアルゴリズムのような小さな機能を紹介する場合があります。Spark コアは機能を紹介しない場合があります。

アルファコンポーネント

新しいコンポーネントが Spark に追加される場合、最初は「アルファ」とマークされることがあります。アルファコンポーネントは上記のガイドラインを遵守する必要はありませんが、可能な限り遵守するよう努めるべきです。「安定」とマークされたら、これらのガイドラインに従う必要があります。

API 互換性

一般に、API とは Spark で文書化されている公開クラスまたはインターフェイスのいずれかを指します。例：ScalaDoc。リリース間のソース互換性とバイナリ互換性の両方を保証するように努めます。

ただし、「開発者 API」および「実験的」な機能であっても、最大限の互換性を維持するように努めます。ユーザーはすべての利用可能な API から最大限の互換性を期待するため、「実験的」としてプロジェクトにマージされたコードは、将来 API を変更する計画がある場合でも、互換性を維持するように努めるべきです。

API の破壊に関する考慮事項

Spark プロジェクトは、メジャーバージョンであっても、API の破壊や無断での動作変更を避けるように努めます。これは常に可能とは限りませんが、API を破壊することを決定する前に、以下の要因のバランスを考慮する必要があります。

API を破壊するコスト

API を破壊することは、Spark のユーザーにとって常にかなりのコストがかかります。API が破壊されると、Spark プログラムはアップグレードする前に書き直す必要があります。ただし、コストを検討する際にはいくつかの考慮事項があります。

• 使用状況 - 多くの場所で積極的に使用されている API を破壊することは、常に非常にコストがかかります。使用状況を確実に知ることは困難ですが、推定する方法はいくつかあります。

  • API は Spark にどのくらい前から存在しますか？

  • API は基本的なプログラムでも一般的ですか？

  • JIRA やメーリングリストで最近の質問をどのくらいの頻度で見かけますか？

  • StackOverflow やブログにどのくらいの頻度で登場しますか？

• 破壊後の動作 - 今日動作するプログラムは、破壊後にどのように動作しますか？以下は、深刻度の順に並べられています。

  • コンパイラまたはリンカエラーが発生しますか？

  • 実行時例外が発生しますか？

  • かなりの処理が完了した後で例外が発生しますか？

  • 異なる結果をサイレントに返しますか？（デバッグが非常に困難で、気づかない可能性もあります！）

API の保守コスト

もちろん、上記のことは、私たちが**決して****いずれか**の API を破壊しないという意味ではありません。問題の API を維持するプロジェクトとユーザー双方のコストも考慮する必要があります。

• プロジェクトコスト - 私たちが持つすべての API はテストされ、プロジェクトの他の部分が変更されても機能し続ける必要があります。これらのコストは、外部依存関係（JVM、Scala など）が変更されると大幅に増幅されます。場合によっては、技術的に完全に不可能ではないとしても、特定の API を保守するコストが高くなりすぎる可能性があります。

• ユーザーコスト - API には、Spark を学習したり、Spark プログラムを理解しようとしたりするユーザーにとって、認知的なコストもあります。問題の API に曖昧または未定義のセマンティクスがある場合、このコストはさらに高くなります。

API 破壊の代替手段

「悪い API」があるが、削除のコストも高い場合、既存のユーザーを傷つけることなく、保守コストの一部に対処できる代替手段を検討する必要があります。

• 悪い API の回避 - これは少し明白ですが、重要な点です。Spark に新しいインターフェイスを追加する際には、この API に永遠に縛られる可能性があることを考慮する必要があります。新しい API が既存の API とどのように関連するか、またそれらが時間とともにどのように進化すると予想されるかを深く考えてください。

• 非推奨警告 - すべての非推奨警告は、明確な代替手段を指す必要があり、単に API が非推奨であることを示すだけではいけません。

• 更新されたドキュメント - ドキュメントは、特定のタスクを実行するための「最良」の推奨方法を指す必要があります。レガシー ドキュメントを維持する場合、新しい API を明確に指し、ユーザーに「正しい」方法を提案する必要があります。

• コミュニティ活動 - 多くの人がブログや StackOverflow などのサイトを読むことで Spark を学習します。しかし、これらのリソースの多くは時代遅れです。最終的に非推奨の API を削除するコストを削減するために、それらを更新してください。

リリース間隔

ブランチは毎年 1 月と 7 月にカットされるため、機能（「マイナー」）リリースは一般的に約 6 か月ごとに行われます。したがって、Spark 2.3.0 は通常 2.2.0 の約 6 か月後にリリースされます。メンテナンスリリースは、機能リリースの間に必要に応じて行われます。メジャーリリースは固定スケジュールでは行われません。

Spark 4.0 リリースウィンドウ

日付	イベント
2025 年 1 月 15 日	コードフリーズ。リリースブランチのカット。
2025 年 2 月 1 日	QA 期間。バグ修正、テスト、安定性、ドキュメントに注力。一般的に、新しい機能はマージされません。
2025 年 2 月 15 日	リリース候補 (RC)、投票など。最終リリースが成功するまで。

メンテナンスリリースと EOL

機能リリースブランチは、一般的に 18 か月間、バグ修正リリースで保守されます。たとえば、ブランチ 2.3.x は、2018 年 2 月の 2.3.0 リリースから 18 か月後の 2019 年 9 月をもって保守されなくなりました。それ以降、バグ修正であっても 2.3.x リリースは期待されるべきではありません。

メジャーリリース内の最後のマイナーリリースは、通常、「LTS」リリースとしてより長く保守されます。たとえば、3.5.0 は 2023 年 9 月 13 日にリリースされ、31 か月後の 2026 年 4 月 12 日まで保守されます。