Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
StrikerRUS opened this issue Jan 14, 2021 · 13 comments
Open

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

StrikerRUS opened this issue Jan 14, 2021 · 13 comments
Labels
good first issue

Comments

@StrikerRUS
Copy link
Collaborator

StrikerRUS commented Jan 14, 2021 •
edited by jameslamb
Loading

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
Copy link
Collaborator Author

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

@jameslamb
Copy link
Collaborator

@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
Copy link
Collaborator Author

StrikerRUS commented Jan 16, 2021 •
edited
Loading

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
Copy link
Collaborator

jameslamb commented Jan 16, 2021 •
edited
Loading

Oh sorry, let me rephrase.

  • there will never be a new R 3.x release
  • there will never be a new Rtools 3.x release

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
Copy link
Collaborator Author

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 jameslamb mentioned this issue Mar 3, 2021
Merged
@jameslamb jameslamb mentioned this issue Apr 3, 2021
Merged
@jameslamb
Copy link
Collaborator

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 jameslamb mentioned this issue Aug 26, 2021
Merged
@StrikerRUS StrikerRUS mentioned this issue Oct 14, 2021
Merged
@tongwu-sh tongwu-sh mentioned this issue Oct 20, 2021
Closed
16 tasks
@StrikerRUS StrikerRUS mentioned this issue Nov 3, 2021
Merged
@StrikerRUS StrikerRUS mentioned this issue Dec 13, 2021
Merged
This was referenced Jan 7, 2022
Closed
Merged
@jameslamb jameslamb mentioned this issue Jan 30, 2022
Merged
@jameslamb jameslamb mentioned this issue Apr 9, 2022
Merged
@StrikerRUS StrikerRUS mentioned this issue Apr 13, 2022
Merged
@StrikerRUS StrikerRUS mentioned this issue Apr 23, 2022
Merged
@jameslamb jameslamb mentioned this issue May 29, 2022
Merged
@jameslamb jameslamb mentioned this issue Nov 16, 2022
Merged
@jameslamb jameslamb mentioned this issue Dec 6, 2022
Merged
@jameslamb
Copy link
Collaborator

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

@jameslamb jameslamb mentioned this issue Sep 3, 2023
Merged
@StrikerRUS
Copy link
Collaborator Author

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
Copy link
Collaborator

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:

  • you and I are the only people who've linked back to this issue or edited it in the 3.5 years since it was opened
  • it takes some effort to keep the links and list of items up to date

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
Copy link
Collaborator Author

@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
Copy link
Collaborator

@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 😄

@jameslamb
Copy link
Collaborator

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.

@borchero borchero mentioned this issue Jul 22, 2024
Open
@jameslamb jameslamb pinned this issue Aug 9, 2024
@jameslamb
Copy link
Collaborator

We had one extra spot in pinned issues, so I decided to pin this for now so it'll be more visible from https://github.com/microsoft/LightGBM/issues

@jameslamb jameslamb mentioned this issue Aug 9, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jameslamb @borchero @StrikerRUS