Xgboost: Roadmap: Bi-monthly release cycles for core lib

Created on 17 Apr 2018  路  13Comments  路  Source: dmlc/xgboost

In the interest of keeping the stable releases up-to-date with the latest master, I'd like to commit to a regular release cycle for the core lib. I propose a bi-monthly release schedule. Here are some time estimates for the upcoming releases:

  • Version 0.72: June 1, 2018
  • Version 0.73: August 1, 2018
  • Version 0.74: October 1, 2018

(Some of these versions may jump to 0.80, if there's any "major" event.)

Some points of discussion

  • Is bi-monthly cycle reasonable interval? I thought of 3 months first, but I didn't want too much a gap between stable release and latest master.
  • Code freezing and backports. @CodingCat suggests that a new branch be created each time a release is made (see discussion in #3200). The release branch will be "frozen" and almost no commits will be added to that branch. Should any backports and post-fixes need to be added, they will be manually cherry-picked into the release branch.
  • Version 1.0 in horizon? IMHO, a good time for this is when the GPU support becomes mature. @RAMitchell and I are working to set up a Jenkins CI server for the GPU code.
  • Binary wheel builds This has been put off for a while. I hope for the day when users can download pre-built binaries with pip install xgboost. Many issue posts today involve installation problems.
  • Versioned docs We need a way to expose XGBoost docs according to stable release versions.

Most helpful comment

0.8- already in , 0.8+ is coming https://github.com/dmlc/xgboost/tree/master/jvm-packages#add-maven-dependency

All 13 comments

@mingwandroid I would highly appreciate your input on this. A regular release schedule should make things predictable for all involved.

We'd like to be more regimented in our builds of XGBoost; getting releases out as soon after you declare them ready as possible so a regular cadence would suit us well. Bi-monthly sounds fine to me from a packager's perspective too.

Sounds great @hcho3

it looks good to me....and I will work on publishing to maven for jvm-package, I think I can make it before the next release

Sounds good to me!

This sounds good. The backporting could take some efforts, and I think one possible way is only promise backporting up to one or two versions

@tqchen

The backporting could take some efforts

I agree. I think we should keep backports to a minimum. Here are two legitimate reasons that I think exist for backports and post-fixes:

  • Urgent fix for e.g. regression, high-impact bug, broken install, security holes etc.
  • Maintenance releases for Python, R, JVM packages that do not modify the core lib. R package in particular has had a series of maintenance releases to keep with CRAN convention

The commits that fall under one of the two would be cherry-picked from the master into the particular release branch. This way, the new system would mostly function like the existing one (versions as tags).

We should still use tags and keep that official. To keep things minimum, maybe what we can do is to keep backport branch up to one version. Say after 0.8 release, the 0.8 branch is kept until 0.9 release and it can be deleted on 1.0 release.

Sorry to go tangential.. 0.80 and 0.90 releases I hope? ;-) After 1.0 dropping this two digit minor version should be entirely possible.

@tqchen I agree. Here is my idea of how things will work in the future:

versioning_system

  • A tag is created for every release
  • Each release branch will have a few commits for backports. Each backport commit is a copy of a commit from the master (the copy being made by git cherry-pick).
  • Release branches are kept around for a while: 0.71 and 0.72 branches will be around until 0.80, for example.

Let me know if you have any input on this diagram.

Let us go ahead and shoot for the next release on June 1, 2018:

  • I will announce the upcoming code freeze on May 25, 2018.
  • The actual code freeze will occur on June 1, 2018. A tag 0.72 will be created, along with a new branch release_0.72.

Thanks everyone!

Howdy, are there any plans on releasing xgboost4j-spark and others into Maven Central repository? thanks.

0.8- already in , 0.8+ is coming https://github.com/dmlc/xgboost/tree/master/jvm-packages#add-maven-dependency

Was this page helpful?
0 / 5 - 0 ratings

Related issues

yananchen1989 picture yananchen1989  路  3Comments

hx364 picture hx364  路  3Comments

choushishi picture choushishi  路  3Comments

trivialfis picture trivialfis  路  3Comments

nicoJiang picture nicoJiang  路  4Comments