このドキュメントは、Apache Hadoopプロジェクトの互換性の目標を記述しています。Hadoop開発者、ダウンストリームプロジェクト、エンドユーザーに影響を与えるHadoopリリース間のさまざまな種類の互換性が列挙されています。このドキュメントでは、各種類の互換性について、
すべてのHadoopインターフェースは、以前のリリースとの互換性を維持するために、対象となるオーディエンスと安定性を基に分類されています。分類の詳細については、Hadoopインターフェース分類を参照してください。
このドキュメントは、Hadoop開発者コミュニティが利用することを目的としています。このドキュメントは、Hadoopプロジェクトへの変更をどのように見なすべきかを説明しています。エンドユーザーやサードパーティの開発者がリリース間の互換性について確信を持つためには、開発者コミュニティは、開発努力がこれらのポリシーに従っていることを確認する必要があります。すべての変更が互換性を維持するか、明示的に互換性がないとマークされていることを検証するのは、プロジェクトコミッターの責任です。
コンポーネント内では、Hadoop開発者はプライベートAPIと限定プライベートAPIを自由に使用できますが、異なるモジュールからのコンポーネントを使用する場合は、サードパーティの開発者と同じガイドラインに従う必要があります。プライベートインターフェースまたは限定プライベートインターフェース（明示的に許可されている場合を除く）を使用せず、代わりに可能な限り安定したインターフェースを進化または不安定なインターフェースよりも優先してください。不可能な場合は、これらの互換性ガイドラインへの例外を導入または永続化させるのではなく、APIの対象範囲を拡大することが好ましい解決策です。Mavenモジュール内で作業する場合は、他のMavenモジュールにあるコンポーネントの使用に関して、可能な限り同じレベルの抑制を遵守する必要があります。
何よりも、Hadoop開発者は、変更の影響を考慮する必要があります。安定したインターフェースは、メジャーリリース間で変更してはなりません。進化するインターフェースは、マイナーリリース間で変更してはなりません。新しいクラスとコンポーネントは、対象となるオーディエンスと安定性を適切にラベル付けする必要があります。さまざまなラベルがいつ適切であるかについては、Hadoopインターフェース分類を参照してください。一般的なルールとして、新しいインターフェースとAPIはすべて、インターフェースまたはAPIの意図を妨げない最も限定的なラベル（例：プライベート不安定）を持つ必要があります。
このドキュメントは、さまざまな互換性の懸念事項に従ってセクションに編成されています。各セクション内では、導入テキストで、そのセクションにおける互換性の意味、重要性、および互換性をサポートする意図について説明します。その後の「ポリシー」セクションでは、統治ポリシーを具体的な用語で設定します。
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119で説明されているように解釈されます。
Java APIは、@Deprecatedアノテーションを提供して、API要素を削除対象としてマークします。アノテーションの標準的な意味は、API要素を使用すべきではなく、後のバージョンで削除される可能性があるということです。
いずれの場合も、APIから要素を削除することは互換性のない変更です。要素の安定性によって、そのような変更がいつ許可されるかが決定されます。安定した要素は、削除される前に完全なメジャーリリースで非推奨としてマークする必要があり、マイナーリリースまたはメンテナンスリリースでは削除してはなりません。進化する要素は、削除される前に完全なマイナーリリースで非推奨としてマークする必要があり、メンテナンスリリース中は削除してはなりません。不安定な要素は、いつでも削除できます。可能であれば、不安定な要素は、削除される前に少なくとも1つのリリースで非推奨としてマークする必要があります。たとえば、Hadoop 2.8でメソッドが非推奨としてマークされている場合、Hadoop 4.0まで削除できません。
安定したAPI要素は、完全なメジャーリリースで非推奨（@Deprecatedアノテーションまたはその他の適切なドキュメントを通じて）としてマークされるまで削除してはなりません。API要素が非推奨として導入された場合（一時的な対策であり、削除されることを示すため）、API要素は次のメジャーリリースで削除できます。安定したAPIを変更する場合は、互換性のない変更を加えるのではなく、新しいメソッドまたはエンドポイントを導入し、既存のメソッドまたはエンドポイントを非推奨とすることを優先する必要があります。
開発者は、すべてのHadoopインターフェースとクラスに@InterfaceAudienceおよび@InterfaceStabilityアノテーションを付与して、対象となるオーディエンスと安定性を記述する必要があります。
アノテーションは、パッケージ、クラス、またはメソッドレベルに適用できます。メソッドにプライバシーまたは安定性に関するアノテーションがない場合、その対象者または安定性レベルは、属するクラスから継承されます。クラスにプライバシーまたは安定性に関するアノテーションがない場合、その対象者または安定性レベルは、属するパッケージから継承されます。パッケージにプライバシーまたは安定性に関するアノテーションがない場合、それぞれプライベートおよび不安定とみなされます。
要素の対象者または安定性に関するアノテーションが、その親（明示的または継承されたもの）の対応するアノテーションと矛盾する場合、要素の対象者または安定性（それぞれ）は、より制限の厳しいアノテーションによって決定されます。たとえば、プライベートメソッドがパブリッククラスに含まれている場合、そのメソッドはプライベートとして扱われます。パブリックメソッドがプライベートクラスに含まれている場合、そのメソッドはプライベートとして扱われます。
互換性ポリシーは、関連するパッケージ、クラス、メンバ変数、またはメソッドのアノテーションによって決定されます。
注：protoファイルから生成されたAPIは、ローリングアップグレードのために互換性がある必要があります。詳細については、ワイヤプロトコル互換性のセクションを参照してください。APIとワイヤプロトコルの互換性ポリシーは、連携する必要があります。
Apache Hadoopは、リリース間でAPIの動作が常に一貫していることを保証しようと努めていますが、正確性のための変更により動作が変更される場合があります。APIの動作は、存在し、完全なJavadoc APIドキュメントによって指定する必要があります。Javadoc APIドキュメントがない場合、動作は関連する単体テストで期待される動作によって指定する必要があります。Javadoc APIドキュメントまたは単体テストカバレッジがない場合、期待される動作は明らかであると推定され、インターフェースの命名によって暗示される最小限の機能であると仮定する必要があります。コミュニティは、より厳密にいくつかのAPIを指定し、仕様への準拠を確認するためのテストスイートを強化することで、容易にテストできる動作のサブセットの正式な仕様を作成する過程にあります。
APIの安定性に応じて、APIの動作は、不正確な動作を修正するために変更できます。このような変更には、既存のドキュメントとテストの更新、および/または新しいドキュメントまたはテストの追加が伴います。
Apache Hadoopのリビジョンは、エンドユーザーアプリケーションが変更なしで動作し続けるように、バイナリ互換性を維持する必要があります。同じメジャーリビジョン内のマイナーApache Hadoopリビジョンは、既存のMapReduceアプリケーション（例：エンドユーザーアプリケーションとApache Pig、Apache Hiveなどのプロジェクト）、既存のYARNアプリケーション（例：エンドユーザーアプリケーションとApache Spark、Apache Tezなどのプロジェクト）、およびHDFSに直接アクセスするアプリケーション（例：エンドユーザーアプリケーションとApache HBase、Apache Flumeなどのプロジェクト）が、元のビルドターゲットと同じメジャーリリース内の任意のApache Hadoopクラスタで使用した場合、修正や再コンパイルなしで動作するように互換性を維持する必要があります。
特にMapReduceアプリケーション（つまり、org.apache.hadoop.mapredおよび/またはorg.apache.hadoop.mapreduce APIを使用するアプリケーション）については、開発者コミュニティはメジャーリリース間でのバイナリ互換性をサポートする必要があります。MapReduce APIは、メジャーリリース間で互換性を持ってサポートされる必要があります。hadoop-1.xとhadoop-2.xの間のMapReduceアプリケーションの互換性の詳細については、こちらを参照してください。
一部のアプリケーションは、ディスクレイアウトまたはその他の内部変更による影響を受ける可能性があります。API以外のインターフェースへの非互換な変更の処理方法に関するポリシーについては、次のセクションを参照してください。
Hadoopには、圧縮、コンテナエグゼキュータバイナリ、さまざまなネイティブ統合など、いくつかのネイティブコンポーネントが含まれています。これらのネイティブコンポーネントは、cmake、gcc、zlibなど、コンパイル時と実行時の両方で、Hadoopのネイティブ依存関係のセットを導入します。このネイティブ依存関係のセットは、Hadoop ABIの一部です。
Hadoopがコンパイル時および/または実行時に依存するネイティブコンポーネントの最小必要なバージョンは、発展中とみなされます。セキュリティ上の問題、ライセンス上の問題、その他の理由による更新は行うことができますが、メジャーバージョン内のマイナーリリース間で最小必要なバージョンを増やすべきではありません。メジャーリリース内のマイナーリリース間でHadoopが依存するネイティブコンポーネントを更新する必要がある場合、可能であれば、メジャーバージョンを変更せずにコンポーネントのマイナーバージョンのみを変更する必要があります。
ワイヤ互換性は、Hadoopプロセス間で「ワイヤを介して」送信されるデータに関するものです。Hadoopは、ほとんどのRPC通信にProtocol Buffersを使用しています。互換性を維持するには、以下に説明する変更を禁止する必要があります。RPC以外の通信も考慮する必要があります。たとえば、スナップショットの一部としてHDFSイメージを転送したり、MapReduceマップタスクの出力を転送するためにHTTPを使用する場合などです。通信は次のように分類できます。
Apache Hadoopのコンポーネントは、Zookeeper、S3、Kerberosなど、独自のプロトコルを含む依存関係を持つ場合があります。これらのプロトコル依存関係は、内部プロトコルとして扱われ、同じポリシーによって管理されます。
プロトコル自体の互換性に加えて、バージョン間の通信を維持するには、サポートされるトランスポートも安定している必要があります。トランスポートの変更のもっともらしい原因は、SSLなどのセキュアトランスポートによるものです。サービスをSSLv2からSSLv3にアップグレードすると、既存のSSLv2クライアントが壊れる可能性があります。セキュリティ上の問題、ライセンス上の問題、その他の理由による更新は行うことができますが、任意のトランスポートのサポートされている最小メジャーバージョンをメジャーバージョン内のマイナーリリース間で増やすべきではありません。メジャーリリース内のマイナーリリース間でトランスポートを更新する必要がある場合、可能であれば、メジャーバージョンを変更せずにコンポーネントのマイナーバージョンのみを変更する必要があります。
サービスポートは、トランスポートメカニズムの一部とみなされます。クライアントを壊さないように、デフォルトのサービスポート番号は一貫性を保つ必要があります。
Hadoopワイヤプロトコルは、.proto（ProtocolBuffers）ファイルで定義されています。クライアント-サーバーおよびサーバー-サーバープロトコルは、.protoファイルに記載されている対象者と安定性の分類に従って分類する必要があります。分類がない場合、プロトコルはプライベートおよび安定であると仮定する必要があります。
.protoファイルへの次の変更は、互換性があるとみなされます。
.protoファイルへの次の変更は、非互換性があるとみなされます。
.protoファイルへの次の変更は、非互換性があるとみなされます。
.protoファイルで定義されていないHadoopワイヤプロトコルは、プライベートおよび安定であるとみなす必要があります。
安定であることによる制限に加えて、Hadoopのワイヤプロトコルは、次のようにメジャーバージョン内のマイナーリリース間で前方互換性も維持する必要があります。
新しい転送メカニズムは、マイナーバージョンまたはメジャーバージョン変更でのみ導入**する必要がある**。既存の転送メカニズムは、メジャーバージョン内のマイナーバージョン間で引き続きサポート**する必要がある**。デフォルトのサービスポート番号は安定と**みなす**べきである。
REST APIの互換性は、公開されたRESTエンドポイント（URL）とレスポンスデータ形式に適用される。Hadoop REST APIは、メジャーバージョンを含め、リリース間でクライアントによる安定した使用を特に目的としている。このドキュメントの目的では、公開されたREST APIとは、公開ドキュメントで説明されているAPIのことである。公開されているREST APIの非網羅的なリストを以下に示す。
各APIには、API固有のバージョン番号がある。互換性のない変更は、APIバージョン番号をインクリメント**する必要がある**。
公開されているHadoop REST APIは、公開かつ進化型と**みなす**べきである。APIバージョン番号に関しては、公開されているHadoop REST APIは、公開かつ安定と**みなす**べきである。つまり、APIバージョン番号内では互換性のない変更は許可されない。REST APIバージョンは、削除される前に、完全なメジャーリリースで非推奨としてラベル付け**する必要がある**。
HadoopデーモンとCLIは、管理者と開発者がクラスタの動作を理解し、トラブルシューティングするためにLog4jを介してログ出力を生成する。ログメッセージは人間の消費を目的としているが、自動化のユースケースもサポートされている。
すべてのログ出力は、公開かつ不安定と**みなす**べきである。ログ出力の場合、互換性のない変更とは、パーサーがログ出力の行を見つけたり認識できなくなってしまう変更のことである。
いくつかのコンポーネントには、システム情報を機械可読形式で記録する監査ログシステムがある。そのデータ形式への互換性のない変更は、既存の自動化ユーティリティを壊す可能性がある。監査ログの場合、互換性のない変更とは、既存のパーサーがログを解析できなくなるような形式を変更するあらゆる変更のことである。
すべての監査ログ出力は、公開かつ安定と**みなす**べきである。データ形式への変更はすべて、互換性のない変更と**みなす**べきである。
メトリクスAPIの互換性はJava APIの互換性によって管理されるが、Hadoopによって公開されるメトリクスデータ形式は、データのコンシューマ（例：自動化タスク）との互換性を維持**する必要がある**。
ユーザーとシステムレベルのデータ（メタデータを含む）は、さまざまな形式のファイルに保存される。メタデータまたはデータ/メタデータを保存するために使用されるファイル形式への変更は、バージョン間の非互換性につながる可能性がある。各ファイル形式のクラスについては、以下で説明する。
エンドユーザーがデータの保存に使用する形式の変更は、それらが後のリリースでデータにアクセスできなくなる可能性があり、したがって互換性を持つことが重要である。これらの形式の例としては、har、war、SequenceFileFormatなどがある。
ユーザーレベルのファイル形式は、公開かつ安定と**みなす**べきである。ユーザーレベルのファイル形式の変更は、メジャーリリース間で前方互換性を持つように**するべき**であり、メジャーリリース内では前方互換性を持つように**する必要がある**。開発者コミュニティは、既存のファイル形式に互換性のない変更を加えるよりも、新しい派生ファイル形式を作成することを優先**するべき**である。このような新しいファイル形式は、オプトインとして作成**する必要がある**。つまり、ユーザーは、明示的に新しいファイル形式の使用を選択しない限り、既存の互換性のある形式を引き続き使用できる必要がある。
Hadoop内部データは、ファイルまたはその他のデータストアにも保存される可能性がある。これらのデータストアのスキーマを変更すると、互換性のない状態になる可能性がある。
MapReduceは、I-Fileなどの形式を使用して、MapReduce固有のデータを保存する。
I-File形式やジョブ履歴サーバーのjhistファイル形式など、すべてのMapReduce内部ファイル形式は、非公開かつ安定と**みなす**べきである。
HDFSは、メタデータ（イメージと編集ログ）を非公開のファイル形式で永続化する。形式またはメタデータのいずれかの互換性のない変更は、後続のリリースが古いメタデータを読み取れなくなる原因となる。互換性のない変更には、既存のメタデータをアップグレードするプロセスを含める必要がある。
変更における非互換性の度合いによっては、次の潜在的なシナリオが発生する可能性がある。
HDFSデータノードは、非公開のディレクトリ構造にデータを保存する。ディレクトリ構造への互換性のない変更は、古いリリースが保存されたデータにアクセスできなくなる可能性がある。互換性のない変更には、既存のデータディレクトリをアップグレードするプロセスを含める必要がある。
HDFSメタデータ形式は、非公開かつ進化型と**みなす**べきである。互換性のない変更には、既存のメタデータをアップグレードするプロセスを含める**必要がある**。アップグレードプロセスでは、複数のアップグレードが必要になる可能性がある。アップグレードプロセスでは、クラスタメタデータを古いバージョンとその古いディスク形式にロールバックできる**必要がある**。ロールバックでは元のデータを復元する**必要がある**が、更新されたデータを復元する**必要はない**。形式への互換性のない変更はすべて、スキーマのメジャーバージョン番号のインクリメントを招く**必要がある**。
データノードのディレクトリ形式は、非公開かつ進化型と**みなす**べきである。互換性のない変更には、既存のデータディレクトリをアップグレードするプロセスを含める**必要がある**。アップグレードプロセスでは、複数のアップグレードが必要になる可能性がある。アップグレードプロセスでは、データディレクトリを古いレイアウトにロールバックできる**必要がある**。
DynamoDBテーブルにメタデータを保存するために使用されるS3Guardメタストア。そのため、互換性戦略を維持する必要があった。S3Guardが削除されたため、テーブルは不要になった。
「null」ストア以外のS3Aメタデータストアを使用するように構成されたアプリケーションは失敗する。
YARNリソースマネージャーは、フェールオーバーとリカバリに使用するために、クラスタ状態に関する情報を外部状態ストアに保存する。状態ストアデータに使用されるスキーマが互換性を維持しない場合、リソースマネージャーは状態を回復できず、起動に失敗する。状態ストアデータスキーマには、互換性を示すバージョン番号が含まれている。
YARNリソースマネージャー状態ストアデータスキーマは、非公開かつ進化型と**みなす**べきである。スキーマへの互換性のない変更はすべて、スキーマのメジャーバージョン番号のインクリメントを招く**必要がある**。スキーマへの互換性のある変更はすべて、マイナーバージョン番号のインクリメントを招く**必要がある**。
YARNノードマネージャーは、リカバリに使用するために、ノード状態に関する情報を外部状態ストアに保存する。状態ストアデータに使用されるスキーマが互換性を維持しない場合、ノードマネージャーは状態を回復できず、起動に失敗する。状態ストアデータスキーマには、互換性を示すバージョン番号が含まれている。
YARNノードマネージャー状態ストアデータスキーマは、非公開かつ進化型と**みなす**べきである。スキーマへの互換性のない変更はすべて、スキーマのメジャーバージョン番号のインクリメントを招く**必要がある**。スキーマへの互換性のある変更はすべて、マイナーバージョン番号のインクリメントを招く**必要がある**。
YARNリソースマネージャーフェデレーションサービスは、レプリケーションとリカバリに使用するために、フェデレートされたクラスタ、実行中のアプリケーション、ルーティングポリシーに関する情報を外部状態ストアに保存する。状態ストアデータに使用されるスキーマが互換性を維持しない場合、フェデレーションサービスは初期化に失敗する。状態ストアデータスキーマには、互換性を示すバージョン番号が含まれている。
YARNフェデレーションサービス状態ストアデータスキーマは、非公開かつ進化型と**みなす**べきである。スキーマへの互換性のない変更はすべて、スキーマのメジャーバージョン番号のインクリメントを招く**必要がある**。スキーマへの互換性のある変更はすべて、マイナーバージョン番号のインクリメントを招く**必要がある**。
Hadoopコマンドラインプログラムは、システムシェルを介して直接、またはシェルスクリプトを介して使用できる。CLIには、hdfsコマンドやyarnコマンドなどのユーザー向けコマンドと、デーモンの起動と停止に使用されるスクリプトなどの管理者向けコマンドの両方がある。コマンドのパスを変更したり、コマンドラインオプションを削除または名前変更したり、引数の順序を変更したり、コマンドの戻りコードと出力を変更したりすると、互換性が損なわれ、ユーザーに悪影響を与える。
実験的であり変更の対象となるものとして文書化されていない限り、すべてのHadoop CLIのパス、使用方法、出力は、公開かつ安定と**みなす**べきである。
CLI出力は、Hadoop CLIによって生成されるログ出力とは別物と**みなす**べきであることに注意すること。後者は、ログ出力に関するポリシーによって管理される**必要がある**。また、CLI出力の場合、すべての変更は互換性のない変更と**みなす**べきであることにも注意すること。
Web UI、特にWebページのコンテンツとレイアウトの変更は、情報を得るためにWebページをスクレイピングしようとする試みを妨げる可能性があります。しかし、Hadoop Web UIページは、自動化などの目的でスクレイピングすることを意図していません。ユーザーは、クラスタ情報をプログラムでアクセスするためにREST APIを使用することが期待されています。
ユーザーは、Hadoopクラスタの動作がリリース間で一貫していることに依存しています。クラスタから予期しない異なる動作を引き起こす変更は、不満と長い導入サイクルにつながる可能性があります。クラスタの設定ファイルが変更されないことを前提として、既存のクラスタの動作を変更する新しい設定を追加すべきではありません。定義される新しい設定については、既存のクラスタの動作を変更しないように注意する必要があります。
既存の機能への変更は、システムまたはロジックの変更、または内部または外部のデフォルト設定値の変更に関係なく、同じマイナーバージョン内のメンテナンスリリース間で、デフォルトの動作または既存の設定の意味を変更してはなりません。
既存の機能への変更は、同じメジャーバージョン内のマイナーリリース間で、デフォルトの動作または既存の設定の意味を変更すべきではありません。ただし、正確性またはセキュリティの問題を修正するための変更などでは、互換性のない動作の変更が必要になる場合があります。可能な限り、そのような動作の変更はデフォルトでオフにする必要があります。
ユーザーは、Hadoopに設定とヒントを提供するためのHadoop定義のプロパティと、ジョブに情報を渡すためのカスタムプロパティを使用します。ユーザーは、Hadoop定義のプロパティの名前空間と競合するカスタム設定プロパティ名を使用しないように推奨され、Hadoopで使用されているプレフィックス（例：hadoop、io、ipc、fs、net、file、ftp、kfs、ha、file、dfs、mapred、mapreduce、yarn）を使用しないようにする必要があります。
プロパティファイルに加えて、Hadoopは、フェアスケジューラ設定ファイルやリソースプロファイル設定ファイルなど、システムの動作を設定するための他の設定ファイルを使用します。
Hadoop定義のプロパティ（名前と意味）は、公開かつ安定と見なされるべきです。Hadoop定義のプロパティによって暗示される単位は、メジャーバージョン間でも変更してはなりません。Hadoop定義のプロパティのデフォルト値は、公開かつ進化と見なされるべきです。
上記のHadoop定義のプロパティに関するルールに準拠していないHadoop設定ファイルは、公開かつ安定と見なされるべきです。互換性のない変更の定義は、特定の設定ファイル形式に依存しますが、一般的なルールとしては、変更前に有効だった設定ファイルは、変更後も有効なままになります。
HadoopデーモンとCLIによって生成されるログ出力は、一連の設定ファイルによって制御されます。これらのファイルは、Hadoopのさまざまなコンポーネントによって出力されるログメッセージの最小レベル、およびそれらのメッセージの保存場所と方法を制御します。
ソースコード、アーティファクト（ソースとテスト）、ユーザーログ、設定ファイル、出力、ジョブ履歴はすべて、ローカルファイルシステムまたはHDFSのいずれかのディスクに保存されます。これらのユーザーがアクセスできるファイルのディレクトリ構造を変更すると、元のパスがシンボリックリンクによって保持されている場合でも（パスがシンボリックリンクに従わないように設定されたサーブレットによってアクセスされる場合など）、互換性がなくなる可能性があります。
ソースコードとビルドアートファクトのレイアウトは、非公開かつ不安定と見なされるべきです。メジャーバージョン内では、開発者コミュニティは全体的なディレクトリ構造を保持する必要がありますが、個々のファイルは警告なしに追加、移動、または削除される場合があります。
Hadoopは、アプリケーションがシステムと対話するために使用するいくつかのクライアントアーティファクトを提供します。これらのアーティファクトは通常、共通ライブラリに独自の依存関係を持っています。これらの依存関係がエンドユーザーアプリケーションまたはダウンストリームコンシューマーに公開されている場合（つまり、シェーディングされていない場合）、これらの依存関係への変更は破壊的になる可能性があります。開発者は、シェーディングなどの手法を使用して、クライアントへの依存関係の公開を避けることを強くお勧めします。
依存関係に関しては、依存関係の追加は互換性のない変更であり、依存関係の削除は互換性のある変更です。
Hadoopに対して構築された一部のユーザーアプリケーションは、アプリケーションのクラスパスにすべてのHadoop JARファイル（Hadoopのライブラリ依存関係を含む）を追加する場合があります。新しい依存関係の追加または既存の依存関係のバージョンの更新は、アプリケーションのクラスパス内のそれらと、その正しい動作に干渉する可能性があります。したがって、ユーザーはこの慣習を採用しないことをお勧めします。
Hadoopクライアントアーティファクトによって公開される依存関係のセットは、公開かつ安定と見なされるべきです。クライアントに公開されていない依存関係（シェーディングされているか、非クライアントアーティファクトにのみ存在するか）は、非公開かつ不安定と見なされるべきです。
ユーザーと関連プロジェクトは、Hadoopによってエクスポートされた環境変数（例：HADOOP_CONF_DIR）を頻繁に使用します。したがって、環境変数の削除または名前変更は、エンドユーザーアプリケーションに影響を与える可能性があります。
Hadoopによって消費される環境変数と、YARNを通じてアプリケーションにアクセス可能になる環境変数は、公開かつ進化と見なされるべきです。開発者コミュニティは、メジャーリリースへの変更を制限する必要があります。
Hadoopはプロジェクト管理にMavenを使用しています。生成されたアーティファクトのコンテンツを変更すると、既存のユーザーアプリケーションに影響を与える可能性があります。
Hadoopテストアーティファクトのコンテンツは、非公開かつ不安定と見なされるべきです。テストアーティファクトには、テストソースコードから生成されたすべてのJARファイルと、ファイル名に「tests」を含むすべてのJARファイルが含まれます。
Hadoopクライアントアーティファクトは、公開かつ安定と見なされるべきです。クライアントアーティファクトは以下のとおりです。
ハードウェア、オペレーティングシステム、JVM、その他のソフトウェアの最新の進歩に対応するために、新しいHadoopリリースには、以前のHadoopリリースよりも新しいハードウェア、オペレーティングシステムリリース、またはJVMバージョンを必要とする機能が含まれている場合があります。特定の環境では、Hadoopをアップグレードするには、他の依存ソフトウェアコンポーネントをアップグレードする必要がある場合があります。
トピックに関連する関連するJIRAとページを以下に示します。