Release version 0.72

[hcho3]

As discussed in #3252, let us release version 0.72 on June 1, 2018.

Here are couple things that will occur:

• On May 31, 2018, 10:00 AM Pacific Time, there will be code freeze for release 0.72.
  • All pull requests (PRs) that are merged to master prior to May 31, 2018 will be part of release 0.72.
  • A new branch release_0.72 has been created. On May 31, I will re-base the branch on top of the last commit of that day.
  • PRs that are not merged by May 31 will not be part of release 0.72 (except for a few reasons as outlined here).
• On June 1, 2018, 10:00 AM Pacific Time, I will create a new tag 0.72 to mark the latest release. I plan to write a release note for 0.72 in NEWS.md.
• On June 1, 2018, I will submit a tarball for 0.72 release to PyPI (Python Package Index).

[RAMitchell]

Can we also upload the GPU binary wheel in this release?

[hcho3]

@RAMitchell Yes, we can submit binary wheels to PyPI, as well as the GitHub release section. Are the GPU wheels also usable for CPU-only machines? (That's what you seem to say in here.)

[RAMitchell]

@hcho3 Yes I believe so. I am testing this on Jenkins by running the GPU compiled wheels in a container without cuda. You should be able to easily grab one of the wheels off Jenkins and try it on your own machine.

[CodingCat]

we are going to have a major changes on xgboost4j-spark, are we open to make it as 0.8 (include some breaking changes) ?

[CodingCat]

the code are currently in spark_dev_do_not_delete branch

[CodingCat]

nvm, we will put the code in the next release

[hcho3]

@CodingCat Okay, let's shoot for releasing 0.80 for the next release date (August 1, 2018).

[hcho3]

I will merge this PR as soon as the tests pass.

[hcho3]

@RAMitchell I'd like to do some test runs on the GPU binary wheel before I upload it to PyPI. Does a binary built with CUDA 9.1 runs on machines with older CUDA toolkits?

[RAMitchell]

@hcho3 I think it should depend on drivers not the toolkit. In any case some gpu support should be better than none. We should announce it as experimental for gpus. The cpu only code should be unaffected regardless.

[codecov-io]

Codecov Report

Merging #3337 into master will increase coverage by 0.69%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3337      +/-   ##
============================================
+ Coverage     45.69%   46.38%   +0.69%     
============================================
  Files           166      103      -63     
  Lines         12973     9960    -3013     
  Branches        466        0     -466     
============================================
- Hits           5928     4620    -1308     
+ Misses         6853     5340    -1513     
+ Partials        192        0     -192

Impacted Files	Coverage Δ	Complexity Δ
python-package/xgboost/sklearn.py	78.49% <0%> (-8.88%)	0% <0%> (ø)
python-package/xgboost/libpath.py	62.5% <0%> (-8.34%)	0% <0%> (ø)
python-package/xgboost/training.py	94.79% <0%> (-1.05%)	0% <0%> (ø)
python-package/xgboost/core.py	81.1% <0%> (-0.63%)	0% <0%> (ø)
...main/java/ml/dmlc/xgboost4j/java/XGBoostError.java
.../src/main/java/ml/dmlc/xgboost4j/java/XGBoost.java
...a/ml/dmlc/xgboost4j/scala/rabit/RabitTracker.scala
...dmlc/xgboost4j/scala/spark/CheckpointManager.scala
...t4j/scala/example/spark/SparkModelTuningTool.scala
...c/main/java/ml/dmlc/xgboost4j/java/XGBoostJNI.java
... and 57 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7cbec4...1467109. Read the comment docs.