search

microsoft / LightGBM

A fast, distributed, high performance gradient boosting (GBT, GBDT, GBRT, GBM or MART) framework based on decision tree algorithms, used for ranking, classification and many other machine learning tasks.
https://lightgbm.readthedocs.io/en/latest/
MIT License
16.41k stars 3.81k forks source link

List of dependencies that should be updated from time to time #3763

Open StrikerRUS opened 3 years ago

StrikerRUS commented 3 years ago

Here is a list of different places in LightGBM's GitHub repo where we specify some dependencies or helpers. Quite often we should specify a particular version of such software. And these versions are tend to obsolete with time. If you see that there is a newer version comparing to what we have, please feel free to propose a PR with updates or simply leave a comment here.

StrikerRUS commented 3 years ago

@jameslamb Please help to clarify. Should we monitor new releases for R 3.x stuff or they have been frozen forever?

jameslamb commented 3 years ago

@jameslamb Please help to clarify. Should we monitor new releases for R 3.x stuff or they have been frozen forever?

No R 3.x resources will change.

Rtools for R 3.x is frozen forever. https://cran.r-project.org/bin/windows/Rtools/history.html

image

We also do not need to look for new versions of R itself. R doesn't have a concept of "long-term support" releases like other projects. So you won't see a bugfix that results in, say, R 4.1.1 and R 3.6.4 at the same time.

You can see the history of release dates at https://cran.r-project.org/bin/windows/base/old/.

StrikerRUS commented 3 years ago

I'm so sorry for my English, but I can read this answer in two ways. Which one is correct? 😄

No, R 3.x resources will change.

No R 3.x resources will change.

Rtools for R 3.x is frozen forever.

Ah, I see, thanks! Removed from the list.

You can see the history of release dates at https://cran.r-project.org/bin/windows/base/old/.

I see there are

R 4.0.3 (October, 2020)
R 4.0.2 (June, 2020)
R 4.0.1 (June, 2020)
R 4.0.0 (April, 2020)

What about 4.0.4? Why we shouldn't wait for it?

jameslamb commented 3 years ago

Oh sorry, let me rephrase.

For 4.x series, there will continue to be new releases. They tend to do 4 or 5 per year. The next release of R will be R 4.1.0. That might or might not involve a new Rtools 4.x release. I use this mirror of the R source (R development is not actually done on GitHub) to keep track: https://github.com/wch/r-source/blob/trunk/VERSION

StrikerRUS commented 3 years ago

Thank you very much! Then I'm removing R 3.x from the list as well.

The next release of R will be R 4.1.0. That might or might not involve a new Rtools 4.x release.

Got it, great! Then I think we can have them both in the list.

They tend to do 4 or 5 per year.

Quite frequent. For instance,

Visual Studio version for OpenCL libraries integration

VS releases have 2-year cycle, but I still find it useful to have VS mentioned here.

jameslamb commented 3 years ago

I want to note here that R 4.1.0 is planned for release on May 18, 2021.

https://twitter.com/pdalgd/status/1383008275545919488

You can see a full list of changes in that version at https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html. There is only one that looks immediately relevant to {lightgbm}, although it's hard to tell since some of the changes are deep in the internals of R and {lightgbm} may indirectly rely on them.

The default C++ standard has been changed to C++14 where available (which it is on all currently checked platforms): if not (as before) C++11 is used if available otherwise C++ is not supported.

Packages which specify C++11 will still be installed using C++11.

Either specify C++11 (see ‘Writing R Extensions’) or modernize the code and if needed specify C++14

I don't think {lightgbm} needs to worry about this, because it already declares its use of C++11 in the way that is recommended by "Writing R Extensions"

I don't think that any action is required at this time to prepare for R 4.1.0. But that release will be a big one so I just wanted to note that it's coming so we're prepared.

jameslamb commented 1 year ago

This project's Windows R-package CI jobs will need to update to a new RTools toolchain, RTools43, once R 4.3 is released.

docs: https://cran.r-project.org/bin/windows/Rtools/rtools43/rtools.html

announcement on the R-pkg-devel mailing list: https://stat.ethz.ch/pipermail/r-package-devel/2023q1/008780.html

StrikerRUS commented 2 weeks ago

Looks like this issue haven't been updated from more than 1.5 year. I guess a lot of things have been changed.

Should we close this issue? @jameslamb

jameslamb commented 2 weeks ago

Many of the things mentioned in this issue have been updated in the last year and a half, but I hadn't started from this issue and so did not remember to link it.

The list is a very useful list of all the places that could be updated and I'd hoped we would get outside contributors helping with this via the good first issue label, but:

Despite that.... I vote that we keep it open. I will try to do a better job of linking back to this in version updates, and can spend some time updating the list and links in the issue description.

I also think there are some opportunities to use more automation for managing versions and to centralize version numbers in fewer places.

For example:

StrikerRUS commented 2 weeks ago

@jameslamb Thanks a lot for your position! Renovate looks interesting! I remember I saw it somewhere in the past but didn't give it a try, unfortunately...

borchero commented 1 week ago

@jameslamb without reading through the entirety of this issue:

SHAs of commits of third-party dependencies

we could also automate this using dependabot just like GH actions :smile:

jameslamb commented 1 week ago

we could also automate this using dependabot just like GH actions

Oh that would be excellent!

I'd support a PR that does that. At this point I'm very confident in this project's CI to catch issues with new versions of those dependencies, and it would be great to integrate bugfixes and performance improvements more often.