RGF-team / rgf

Home repository for the Regularized Greedy Forest (RGF) library. It includes original implementation from the paper and multithreaded one written in C++, along with various language-specific wrappers.
378 stars 58 forks source link

update to CRAN version 1.0.8 #346

Closed mlampros closed 3 years ago

mlampros commented 3 years ago

I've updated the R package to CRAN version 1.0.8 and,

I am aware of the discussion in #338 therefore I've set as Reviewer only @StrikerRUS. In any other case, just tell me and I'll add Reviewers. Thanks.

mlampros commented 3 years ago

Just a reminder so that the tests run in the Github repository but not on CRAN. We have to set the reticulate::py_available(initialize = TRUE) in the "package.R" file

StrikerRUS commented 3 years ago

I have one question which is not about this particular PR but is related to the CRAN submission process. How will you update the package on CRAN based on the review comments here?

mlampros commented 3 years ago

I have one question which is not about this particular PR but is related to the CRAN submission process. How will you update the package on CRAN based on the review comments here?

I didn't include the citation at the end of the README.md file in my CRAN submission (you can have a look towards the end of the README.md file)

The only change that remains is the year of the 'rgf_python' citation and the url of the citation. Do you think I should resubmit a new version with the purpose to change the year of the citation? Otherwise, these updates will be visible in the next version once I'll clone again this repository.

StrikerRUS commented 3 years ago

The only change that remains is the year of the 'rgf_python' citation and the url of the citation. Do you think I should resubmit a new version with the purpose to change the year of the citation?

Does CRAN allow to submit fixed code without incrementing a version? Of course, I don't think that dynamic year in citation doesn't worth to upload a new version. But this case has uncovered some problems in the R-package development process, I believe. I guess some reordering is needed. For example, make changes in the R-package code, prepare a PR with them, go thought a review process, merge into master and only after these steps upload new version to CRAN. Intermediate checks to make sure that ERROR/WARNING/NOTE has gone can be done with the help of R-hub service, for instance. Or it is possible to upload on CRAN some development version only with the aim to use their custom R infrastructure to check test results, where current_master_version < dev_version < next_version.

I believe by doing so we will guarantee the synchronization between the code on GitHub and on CRAN and avoid situations like the current one. Please let me know WDYT about this!

mlampros commented 3 years ago

yes, I agree.