Xgboost: XGBoost 0.90 路线图

因为我们将进行重大更改，例如https://github.com/dmlc/xgboost/pull/4349和https://github.com/dmlc/xgboost/pull/4377

我们应该将版本提升到 0.9 吗？

@CodingCat当然，如果突破性变化很大，我们可以达到 0.90。 你能帮我一个忙，写一段关于为什么需要#4349的描述吗？

当然，

* 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 这将使 2.3.x 在大约 7 月的 EOL 上发布，因此不会期望在此之后有更多的 2.3.x 版本来自 OSS 项目。

@srowen谢谢！

@srowen @CodingCat @alexvorobiev让我们也讨论一下支持 Scala 2.12 / 2.13 的可能性。 现在，XGBoost4J 是为 Scala 2.11 编译的：
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

一位用户报告说，为 Scala 2.11 编译的 XGBoost4J JAR 与 Scala 2.12 二进制不兼容。

是的，2.11 / 2.12 仍然是二进制不兼容的，Spark 有两个发行版。 尽管 2.12 是 2.4.x 中的默认值，但 2.4.x 中都支持两者。 3.0 将放弃对 Scala 2.11 的支持。

这可能只是编译两个版本的问题，而不是太多或任何代码更改。 如果您在 2.12 中遇到任何有趣的错误，请告诉我，因为我在更新 Spark 时关注了很多这些问题。

2.13 仍然不是 GA，并且认为从 2.12->2.13 的变化比 2.11->2.12 的变化要小（这里的大区别是 lambda 的完全不同的表示）。

@hcho3我想你想标记@alexvorobiev？

@alexeygrigorev哎呀，抱歉。

唯一的问题是我们需要对 maven 中 xgboost 的工件名称进行重大更改，xgboost4j-spark => xgboost4j-spark_2.11/xgboost4j-spark_2.12，例如 spark https://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 版本。

是的，默认的 Spark 2.4.x 版本将用于 2.11； -Pscala-2.12获取 2.12 版本。

谢谢，至少在即将到来的版本中，我会保守地支持 2.12

据我所知，大多数 Spark 用户仍在使用 2.11，因为他们习惯于遵循以前版本的 Spark

我可能没有带宽来完成引入 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 什么时候出来吗？

我觉得稍微延迟一下就好了

好的，等Spark 2.4.3出来吧

Spark 2.3.x 会有最新的 0.83 版本吗？

@CodingCat如果我们制作两个并行版本 0.83 和 0.90，其中 0.83 包括#4377 之前的所有提交，会怎样？ 0.83 版本将仅作为 JVM 包发布，Python 和 R 包将获得 0.90。 对我来说不会再有任何工作了，因为无论如何我都必须为 0.90 编写发行说明。

但是，一个问题是缺失值处理的用户体验。 也许强制每个人都使用 Spark 2.4.x 可以防止他们弄乱缺失值（激发#4349 的问题）

@hcho3我有点担心不同版本在 pkgs 可用性方面的不一致。

我可以想象像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/905c06304a5a2f6304a5a5a84a5a5a83e7d585

2. 另一方面，除了烧掉所有提交者之外，为了使社区可持续，我们应该定期放弃对以前版本的支持

3. 应该通过功能发布（从 0.8 到 0.9）将创新和改进带给用户

如果我们决定使用 0.83，我们还需要从@RAMitchell @trivialfis收集意见，并使用他们的判断来查看我们是否有他们注意到的重要（更多关于正确性）的错误修复

然后创建一个基于 0.82 的 0.83 分支来挑选提交......实际上有很多工作

如果我理解正确，0.9 将不支持旧版本的 spark，因此建议支持 0.83 版本和 0.9 以继续支持旧的 spark 版本，同时包括错误修复？

一般来说，我反对任何使用开发人员时间的东西。 我们还不够忙吗？ 但是，我确实看到了稳定版本的一些价值。

@CodingCat有没有办法在不升级到 Spark 2.4.x 的情况下合并错误修复（2d875ec 和 995698b）？

如果发布维护版本不仅仅是削减分支（例如需要挑选），我宁愿不做出这样的承诺。

一般来说，我反对任何使用开发人员时间的东西。 我们还不够忙吗？

我同意。

@CodingCat有没有办法在不升级到 Spark 2.4.x 的情况下合并错误修复（2d875ec 和 995698b）？

@hcho3不幸的是没有，由于 Spark 依赖的库发生了重大变化，我们只能使用一致版本的 spark 编译和运行 xgboost

如果将来我们对维护版本感兴趣，工作流程（发布 0.9 后）

1. 向后移植到 0.9-branch 的必要修复

2. 每 2 个月发布 0.9 倍，或者由重要的错误修复触发

3. 主要功能和所有向后移植到 0.9x 的修复程序都应该在主版本中可用

4. 当发布 1.0 时，从 master 上剪下一个分支......

但同样，一旦我们在 master 中进行了大的重构并希望在此之后将修复程序向后移植到 0.9 ......大量的工作

@CodingCat鉴于当前开发社区的规模，让我们将精力放在维护版本上。

@tovbinm抱歉，由于带宽不足，我认为我们无法发布 0.83 版本。 升级到 Spark 2.4.3 对您来说可行吗？

那真不幸。 不，短期内不会。 我们仍在 2.3.x 上。

将 Spark 从 2.3 升级到 2.4 的提交是什么？ 也许我们可以在那里削减（当然如果它高于 0.82）。

@tovbinm您可以使用提交 711397d6452d596d7acbb68f1052ffebdee3e3af 构建 XGBoost 以使用 Spark 2.3.x。

伟大的。 那么为什么不从那个提交中公开发布呢？

正如@CodingCat所说，维护版本不仅仅是在提交之前进行剪切的问题。 此外，公开发布是隐含的支持承诺。 我认为维护者目前不会支持两个新版本。

关于我们是否应该从 711397d6452d596d7acbb68f1052ffebdee3e3af 发布，我将遵循@CodingCat

带有 GPU 预测器的外部内存 - 这意味着代码不会因 what(): std::bad_alloc: out of memory 而崩溃？ （即临时交换到 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-Gerlach 我们会在发布 1.0 时考虑它。 另一方面，我们不想急于进入 1.0。 我们希望 1.0 在功能、稳定性和性能方面成为某种里程碑。

感谢您的解释， @hcho3 。

你可能想确保你设置python_requires参数'>=3.5'的setup() ，以保证用户使用Python 2不因意外而升级到版本不兼容。

@hcho3 GPU 算法无法使用外部内存

@hlbkin你是对的。 外部内存将仅可用于 GPU 预测器，不可用于训练。

@ronou @sriramch我对 GPU 训练不适用于外部存储器的

@hcho3是的，你是对的。 我们正在做这件事。 如果您有兴趣，更改在这里。 我必须与 master 同步此更改并编写一些测试。

@sriramch 太棒了！ 我们的目标是在 0.90 版本中包含外部记忆训练，还是应该在 0.90 版本之后重新使用它？

只是我的两分钱，让我们保留一些在 0.x 中压缩许多新功能（以匆忙的方式）并考虑将哪些内容作为里程碑版本放入 1.0

@CodingCat我同意。 仅供参考，我从 0.90 路线图中删除了分布式自定义目标，因为在 #4280 中存在重大分歧。 我们会在 0.90 之后再次考虑。

@sriramch让我们考虑 0.90 版本后的外部记忆训练。 非常感谢您的辛勤工作。

这可能是发布 cuda 9.0 二进制文件而不是 8.0 的好时机。 我认为用户驱动程序版本现在将充分支持 9.0。 此外，9.0 二进制文件不需要针对较新的 Volta 架构进行 JIT 编译。

@hcho3我们准备好了吗？

几乎。 我认为#4438 应该合并。

现在一切都很好。 我将继续并开始处理下一个版本。 预计到达时间：2019 年 5 月 16 日

• [x] 在setup.py需要 Python 3
• [x] 更改 CI 以构建 CUDA 9.0 轮子 (#4459)
• [x] 修复 Windows 编译 (#4463)
• [x] 使用 GPU 为 Windows 设置最小可行 CI (#4463)

@RAMitchell我们应该使用 CUDA 9.0 还是 9.2 来发布车轮？

让我们使用 9.2，因为它已经在 CI 上设置好了。 危险在于我们需要太新的 Nvidia 驱动程序。 作为参考，这里是显示 cuda 版本和驱动程序之间对应关系的表格： https: //docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

据我所知，这无论如何都不会影响 CPU 算法。 如果用户开始报告问题，那么我们可以在未来通过更好的驱动程序兼容性错误消息来解决这个问题。

嗯，在这种情况下，我可以尝试将 CI 工作人员之一降级到 CUDA 9.0。 由于我们广泛使用 Docker 容器，所以应该不会太难。

我现在准备发布 0.90 版本。 我的目标是在本周末完成发行说明。

已关闭 #4475