XGBoost Release Policy

Versioning Policy

Starting from XGBoost 1.0.0, each XGBoost release will be versioned as [MAJOR].[FEATURE].[MAINTENANCE]

  • MAJOR: We guarantee the API compatibility across releases with the same major version number. We expect to have a 1+ years development period for a new MAJOR release version.

  • FEATURE: We ship new features, improvements and bug fixes through feature releases. The cycle length of a feature is decided by the size of feature roadmap. The roadmap is decided right after the previous release.

  • MAINTENANCE: Maintenance version only contains bug fixes. This type of release only occurs when we found significant correctness and/or performance bugs and barrier for users to upgrade to a new version of XGBoost smoothly.

Making a Release

  1. Create an issue for the release, noting the estimated date and expected features or major fixes, pin that issue.

  2. Create a release branch if this is a major release. Bump release version. There’s a helper script tests/ci_build/change_version.py.

  3. Commit the change, create a PR on GitHub on release branch. Port the bumped version to default branch, optionally with the postfix SNAPSHOT.

  4. Create a tag on release branch, either on GitHub or locally.

  5. Make a release on GitHub tag page, which might be done with previous step if the tag is created on GitHub.

  6. Submit pip, CRAN, and Maven packages.

    • The pip package is maintained by Hyunsu Cho and Jiaming Yuan. There’s a helper script for downloading pre-built wheels and R packages xgboost/dev/release-pypi-r.py along with simple instructions for using twine.

    • The CRAN package is maintained by Tong He and Jiaming Yuan.

    • The Maven package is maintained by Nan Zhu and Hyunsu Cho.

R CRAN Package

Before submitting a release, one should test the package on R-hub and win-builder first. Please note that the R-hub Windows instance doesn’t have the exact same environment as the one hosted on win-builder.

According to the CRAN policy:

If running a package uses multiple threads/cores it must never use more than two simultaneously: the check farm is a shared resource and will typically be running many checks simultaneously.

We need to check the number of CPUs used in examples. Export _R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2.5 before running R CMD check --as-cran [1] and make sure the machine you are using has enough CPU cores to reveal any potential policy violation.

References

[1] https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008610.html