Xgboost: XGBoost0.90ロードマップ

https://github.com/dmlc/xgboost/pull/4349やhttps://github.com/dmlc/xgboost/pull/4377のような重大な変更が予定されているため

バージョンを0.9に上げましょうか。

@CodingCat確かに、重大な変更が重要な場合は、0.90に

承知しました、

* Spark 2.3 is reaching its end-of-life in a few months

それについての公式声明はありますか？ 彼らは1月に2.2.3、2月に2.3.3をリリースしました。 私たちのベンダー（MapR）はまだ2.3.1を出荷しています。

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 、あなたはdatabricksから@srowenで確認することができます

これはDatabricksの質問ではなく、Sparkプロジェクトの質問です。 デフォルトのポリシーは、18か月間のブランチのメンテナンスリリースです。https ：//spark.apache.org/versioning-policy.htmlこれにより、7月頃にEOLで2.3.xがリリースされるため、その後2.3.xのリリースが増えることはありません。 OSSプロジェクトからのものです。

@srowenありがとう！

@srowen @CodingCat @alexvorobiev Scala 2.12
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

ユーザーは、Scala2.11用にコンパイルさと報告しました。

ええ、2.11 / 2.12はまだバイナリ互換ではなく、Sparkには2つのディストリビューションがあります。 どちらも2.4.xでサポートされていますが、2.4.xではこれ以降2.12がデフォルトになります。 3.0ではScala2.11のサポートが終了します。

コードを大幅に変更するのではなく、2つのバージョンをコンパイルするだけの問題かもしれません。 2.12でおかしなエラーが発生した場合は、Sparkの更新時にこれらの問題をたくさん見つめていたので、お知らせください。

2.13はまだGAではなく、2.12-> 2.13から2.11-> 2.12よりも小さな変更になると思います（ここでの大きな違いは、ラムダの表現がまったく異なることです）。

@ hcho3 @alexvorobievにタグを付けたいと思いますか？

@alexeygrigorevおっと、ごめんなさい。

唯一の問題は、Mavenのxgboostのアーティファクト名xgboost4j-spark => xgboost4j-spark_2.11 / xgboost4j-spark_2.12に、sparkhttps：//mvnrepository.com/artifact/のように重大な変更を導入する必要があることです。 org.apache.spark / spark-coreであり、2.11に一時的に依存しているかどうかを再確認する必要があります（私はそうは思いません）

こんにちは、 @ srowen though 2.12 is the default from here on in 2.4.x 、branch-2.4 pom.xmlをチェックしました。プロファイルscala-2.12を指定しない場合でも、2.11ビルドが得られますね。

0.9xで2.12のみをサポートすることを選択でき、アーティファクト名に接尾辞を付ける必要はありません。 両方をサポートしている場合は、残念ながらアーティファクト名を変更して、_2.11バージョンと_2.12バージョンを使用する必要があります。

はい、デフォルトのSpark2.4.xビルドは2.11用になります。 -Pscala-2.12は2.12ビルドを取得します。

おかげで、少なくとも次のバージョンでは2.12をサポートすることに慎重になります

私の知る限り、Sparkユーザーのほとんどは以前のバージョンのSparkをフォローすることに慣れているため、まだ2.11を使用しています。

2.12サポートを導入するために持っているすべてのテストを通過するための帯域幅がない可能性があります

1.0リリースで2.12 + 2.11または2.12をサポートすることを選択します...

@ hcho3参考までに、帯域幅が限られているため、ロードマップから密行列のサポートを削除しました

@ hcho3時間が許せば、 https：//github.com/dmlc/dmlc-core/pull/514をご覧ください。 次のリリースがヒットする前にマージする価値があるかもしれません。

@trivialfisはそれを見ます

@CodingCat Spark 2.4.1と2.4.2には問題があるため、リリース日を

@srowen Spark 2.4.3がいつ

少し遅れても大丈夫だと思います

さて、Spark2.4.3がリリースされるまで待ちましょう

Spark 2.3.xの最後の0.83リリースはありますか？

@CodingCat 2つの並列リリース0.83と0.90を作成するとどうなりますか？0.83には＃4377の直前のすべてのコミットが含まれますか？ 0.83バージョンはJVMパッケージとしてのみリリースされ、PythonおよびRパッケージは0.90を取得します。 とにかく0.90のリリースノートを書かなければならないので、それは私にとってこれ以上の仕事ではありません。

ただし、1つの問題は、欠測値の処理に関するユーザーエクスペリエンスです。 たぶん、全員にSpark 2.4.xの使用を強制することで、欠落している値を台無しにするのを防ぐことができます（＃4349の動機となった問題）

@ hcho3pkgsの可用性における異なるバージョンの不一致について少し心配しています。

hey, I find 0.83 in maven so I upgrade our Spark pkg, but I cannot use 0.83 in notebook when attempting to explore my new model setup with a small amount of data with python pkg?ような質問を想像できます

0.8xブランチで完全なメンテナンスリリースがあるか、何もないことをお勧めします

@CodingCat了解しました。 すべてのパッケージに対して一貫したリリースを行います。 では、0.83リリースについてどう思いますか？ 私たちはそれをすべきですか？

@CodingCat実際、これは他のメンテナのための仕事を作成します、私たちは最初に彼らに尋ねる必要があります

個人的な見解からの短い答えは理論的には

これが0.8xのようなメンテナンスリリースについてどう考えるべきかについての私の2セントです

1. メンテナンスリリースを用意する理由は、 https：//github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51やhttps://github.com/dmlc/xgboost/commit/995698b0cb1da75f066d7e0531302a3などの重大なバグ修正を導入するためです

2. 一方、すべてのコミッターを焼き尽くす以外にコミュニティを持続可能なものにするために、以前のバージョンのサポートを定期的に中止する必要があります

3. イノベーションと改善は、機能リリースを通じてユーザーに提供する必要があります（0.8から0.9にジャンプ）

0.83に進むことにした場合は、 @ RAMitchell @trivialfisからも意見を収集し、彼らの判断を使用して、彼らが気付いた重要な（正確性についての）バグ修正があるかどうかを確認する必要があります。

次に、0.82に基づいて0.83ブランチを作成し、コミットを選択します......実際には多くの作業が必要です

私が正しく理解していれば、0.9は古いバージョンのsparkをサポートしません。したがって、バグ修正を含めながら、古いバージョンのSparkを引き続きサポートするために0.83バージョンと0.9をサポートするという提案はありますか？

一般的に、私は開発者の時間を使うものには反対です。 もう忙しくないですか？ ただし、安定バージョンを使用することにはある程度の価値があります。

@CodingCat Spark 2.4.xにアップグレードせずにバグ修正（2d875ecおよび995698b）を組み込む方法はありますか？

メンテナンスリリースを作成することが単に枝を切るだけではない場合（たとえば、チェリーピックの必要性）、私はそのようなコミットメントをしたくありません。

一般的に、私は開発者の時間を使うものには反対です。 もう忙しくないですか？

同意します。

@CodingCat Spark 2.4.xにアップグレードせずにバグ修正（2d875ecおよび995698b）を組み込む方法はありますか？

@ hcho3残念ながら、Sparkに依存するライブラリの

将来、メンテナンスリリース、ワークフロー（0.9のリリース後）に関心がある場合

1. 0.9ブランチへのバックポートの必要な修正

2. たとえば2か月ごとに0.9xをリリースするか、重要なバグ修正によってトリガーされます

3. 0.9xにバックポートされた主要な機能とすべての修正はマスターで利用可能である必要があります

4. リリース1.0の場合、マスターからブランチを切り取ります......

しかし、繰り返しになりますが、マスターに大きなリファクタリングがあり、その後修正を0.9にバックポートしたい場合...大量の作業

@CodingCat開発コミュニティの現在のサイズを考慮して、メンテナンスリリースをパントしましょう。

@tovbinm申し訳ありませんが、帯域幅が不足しているため、0.83リリースを実行できないと思います。 Spark 2.4.3へのアップグレードは可能ですか？

それは残念です。 いいえ、短期的ではありません。 私たちはまだ2.3.xを使用しています。

Sparkを2.3から2.4にアップグレードしたコミットは何ですか？ おそらくそこでカットすることができます（もちろん0.82を超えている場合）。

@tovbinmコミット711397d6452d596d7acbb68f1052ffebdee3e3afを使用してXGBoostをビルドし、Spark2.3.xを使用できます。

素晴らしい。 では、そのコミットから公開リリースを作成してみませんか？

@CodingCatが言ったように、メンテナンスリリースは単にコミット前にカットするだけの問題ではありません。 また、公開リリースを行うことは、サポートの暗黙の約束です。 現時点では、メンテナが2つの新しいリリースをサポートする準備ができているとは思いません。

711397d6452d596d7acbb68f1052ffebdee3e3afからリリースする必要があるかどうかについては、@ CodingCatに従います。

GPUプレディクターを備えた外部メモリ-これは、コードがwhat（）でクラッシュしないことを意味します：std :: bad_alloc：メモリ不足ですか？ （つまり、一時的にRAMにスワップしますか？）

関連する問題https://github.com/dmlc/xgboost/issues/4184-これは主にメモリの一時的なバーストであり、フィッティング自体のプロセスはそれほど多くのメモリを必要としません

@hlbkin https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.htmlによると、外部メモリを明示的に有効にする必要があり

メジャーバージョンバンプ（つまり1.0）がないと切り替えることはできないと思いますが、切り替える場合は、準拠したPEP 440バージョン番号（iexyz）、できればセマンティックバージョニングのサポートを検討できますか？ 0.90（0.9.0ではなく）の標準的な解釈は、メジャーバージョン0.x（つまり、安定版リリース前）シリーズの90番目のマイナーリリースであり、0.83以下であるというものです。 さらに、これにより、マイナーバージョンごとに最大9ポイントのリリースに制限され、一部のツール（およびユーザー）が解釈するのが困難になります。 ありがとう！

+1

@ CAM-Gerlach1.0をリリースするときに検討します。 一方で、1.0に急いで行きたくはありません。 1.0は、機能、安定性、パフォーマンスの点で、ある種のマイルストーンになることを望んでいます。

説明をありがとう、 @ hcho3 。

あなたはおそらく、あなたが設定したいpython_requiresに引数を'>=3.5'でsetup()のPython 2と、ユーザーが誤って、互換性のないバージョンにアップグレードされません確実にするために。

@ hcho3外部メモリはGPUアルゴリズムでは使用できません

@hlbkinその通りです。 外部メモリはGPUプレディクターでのみ使用でき、トレーニングでは使用できません。

@rongou @sriramch GPUトレーニングが外部メモリでは利用できないというのは正しいですか？

@ hcho3はいあなたは正しいです。 我々はそれに取り組んでいます。 興味があれば、変更はここにあります。 この変更をマスターと同期して、いくつかのテストを作成する必要があります。

@sriramch素晴らしい！ 0.90リリースに外部メモリトレーニングを含めることを目指すべきですか、それとも0.90後に戻ってくるべきですか？

ちょうど私の2セント、0.xで多くの新機能を（急いで）圧縮することに少し予約して、マイルストーンバージョンとして1.0に何を入れるかを考えてみましょう

@CodingCat同意します。 参考までに、＃4280にかなりの不一致があったため、0.90ロードマップから分散カスタマイズ目標を削除しました。 0.90以降に再度検討します。

@ sriramch0.90リリース後の外部メモリトレーニングについて考えてみましょう。 大変お世話になりました。

これは、8.0ではなくcuda9.0バイナリをリリースする良い機会かもしれません。 9.0はユーザードライバーバージョンで十分にサポートされるようになると思います。 さらに、9.0バイナリは、新しいVoltaアーキテクチャ用にJITコンパイルする必要はありません。

@ hcho3準備はいいですか？

ほとんど。 ＃4438をマージする必要があると思います。

今はすべて良いです。 私は先に進み、次のリリースに取り組み始めます。 ETA：2019年5月16日

• [x] setup.py Python3が必要
• [x] CIを変更してCUDA9.0ホイールを構築する（＃4459）
• [x] Windowsのコンパイルを修正しました（＃4463）
• [x] GPUを搭載したWindows用の最小限の実行可能なCIをセットアップする（＃4463）

@RAMitchellホイールリリースに

CIですでに設定されている9.2を使用してみましょう。 危険なのは、新しすぎるNvidiaドライバーが必要になることです。 参考までに、cudaバージョンとドライバーの対応を示す表を示します：

私の知る限り、これはとにかくCPUアルゴリズムに影響を与えるべきではありません。 ユーザーが問題を報告し始めた場合は、ドライバーの互換性に関するエラーメッセージを改善することで、将来的にこれに対処できます。

その場合は、CIワーカーの1つをCUDA9.0にダウングレードしてみることができます。 Dockerコンテナーを広範囲に使用しているので、それほど難しくはありません。

今から0.90リリースを準備します。 私の目標は、今週の終わりまでにリリースノートを完成させることです。

＃4475で閉鎖