バージョン管理ポリシー

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

Sparkのバージョン

各Sparkリリースは次のようにバージョン管理されます： [メジャー].[機能].[メンテナンス]

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

アルファコンポーネント

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

API互換性

APIとは、Sparkで公開されている、「開発者API」または「実験的」とマークされていないすべてのパブリッククラスまたはインターフェースです。リリースAは、リリースAに対してコンパイルされたコードがリリースBに対して*クリーンにコンパイルされる*場合、リリースBとAPI互換性があります。現在、バージョンAにリンクされているコンパイル済みアプリケーションが、再コンパイルせずにバージョンBにクリーンにリンクすることを保証するものではありません。リンクレベルの互換性は、将来のリリースで保証しようとしているものです。

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

APIを破壊する場合の考慮事項

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

APIを破壊するコスト

APIを破壊することは、ほとんどの場合、Sparkのユーザーにとって些細なコストではありません。APIが壊れているということは、Sparkプログラムをアップグレードする前に書き直す必要があることを意味します。ただし、コストがどうなるかを考える際に、いくつかの考慮事項があります。

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

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

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

  • JIRAまたはメーリングリストで最近の質問がどれくらいの頻度で見られますか？

  • Stack Overflowやブログにどれくらいの頻度で表示されますか？

• **破壊後の動作** - 現在機能しているプログラムは、破壊後にどのように動作しますか？以下は、重大度の低い順に大まかにリストされています

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

  • ランタイム例外が発生しますか？

  • かなりの処理が行われた後にその例外が発生しますか？

  • 異なる答えを黙って返しますか？（デバッグが非常に難しく、気付かない可能性もあります！）

APIを維持するコスト

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

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

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

APIを破壊する代わりに

「悪いAPI」があるが、削除のコストも高い場合は、既存のユーザーに悪影響を与えることなく、メンテナンスコストの一部に対処できる代替案を検討する必要があります。

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

• 廃止警告 - すべての廃止警告は明確な代替手段を示している必要があり、APIが廃止されたとだけ言ってはいけません。

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

• コミュニティ活動 - 多くの人はブログやStack Overflowなどの他のサイトを読んでSparkを学びます。ただし、これらのリソースの多くは古くなっています。廃止されたAPIを最終的に削除するコストを削減するために、それらを更新してください。

リリース頻度

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

Spark 3.5 リリース期間

日付	イベント
2023年7月16日	コードフリーズ。リリースブランチカット。
2023年7月下旬	QA期間。バグ修正、テスト、安定性、ドキュメントに焦点を当てます。一般的に、新しい機能はマージされません。
2023年8月	リリース候補（RC）、投票など、最終リリースが合格するまで

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

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

メジャーリリース内の最後のマイナーリリースは、通常、「LTS」リリースとしてより長く維持されます。たとえば、2.4.0は2018年11月2日にリリースされ、2021年5月に2.4.8がリリースされるまで31か月間維持されていました。2.4.8は最後のリリースであり、バグ修正であっても2.4.xリリースはこれ以上期待されません。