release 3.1.1

[jameslamb]

PR for release 3.1.1. This is a bugfix release, so feature or breaking PRs like #3405, #3515, and #3581 should not be merged into it.

I created this on a LightGBM branch so any maintainer can push to it.

Release checklist:

The PRs added to the checklist below are based on #3586 (comment)

• Update VERSION.txt number.
• Update version in Appveyor config file.
• Update version in configure file of R-package.
• merge [R-package] construct dataset earlier in lgb.train and lgb.cv (fixes #3583) #3598
• merge Check max_bin, etc. match config when using binary #3592
• fix [R-package] R CMD CHECK note 'partial argument match' #3629
• run R valgrind checks after all PRs are merged
• run R Solaris checks after all PRs are merged
• Push commit with v* tag to trigger GitHubRelease action at Azure Pipelines.
• Convert automatic GitHub release from Draft to normal one.
• Update stable tag at GitHub.
• Upload release to PyPI.
• Upload release to CRAN.
• Update cran-comments.md when 3.1.1 is accepted on CRAN
• Upload release to NuGet.
• Update version and hash in Homebrew formula.

[jameslamb]

I just updated this branch with the changes from #3592. Will run the Solaris and valgrind checks on the R package right now.

[jameslamb]

/gha run r-valgrind

[jameslamb]

this will probably take 40-60 minutes: https://github.com/microsoft/LightGBM/actions/runs/402978050

[jameslamb]

I'll use this comment thread for all R-related issues so this PR doesn't pick up too many comments and we can resolve it all at once.

good news: tests are passing on Solaris and on Windows 32-bit!
bad news: there is a NOTE from R CMD CHECK that I think was introduced by the work for #3390

• checking R code for possible problems ... NOTE
  partial argument match of 'data' to 'dataset'
  lgb.cv : : warning in getinfo(data = data, name =
  "init_score"): partial argument match of 'data' to 'dataset'
  lgb.cv : : warning in getinfo(data = data, name = "weight"):

I'll open a separate PR to fix this and to make sure we catch it in CI. Should be quick.

[jameslamb]

I can see this NOTE in recent builds in CI: https://github.com/microsoft/LightGBM/runs/1502651682

it wasn't caught because the "CRAN incoming note" is no longer thrown now that the package is on CRAN.

https://github.com/microsoft/LightGBM/runs/1502651682

[jameslamb]

valgrind looks happy! This is the same output we had for 3.1.0 which was accepted by CRAN.

==2062== Memcheck, a memory error detector
==2062== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2062== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==2062== Command: /usr/local/RDvalgrind/lib/R/bin/exec/R --no-readline --vanilla -f testthat.R
==2062== 
Loading required package: R6
==2062== Conditional jump or move depends on uninitialised value(s)
==2062==    at 0x49CF138: gregexpr_Regexc (grep.c:2439)
==2062==    by 0x49D1F13: do_regexpr (grep.c:3100)
==2062==    by 0x49A0058: bcEval (eval.c:7121)
==2062==    by 0x498B67F: Rf_eval (eval.c:727)
==2062==    by 0x498E414: R_execClosure (eval.c:1895)
==2062==    by 0x498E0C7: Rf_applyClosure (eval.c:1821)
==2062==    by 0x499FC8C: bcEval (eval.c:7089)
==2062==    by 0x498B67F: Rf_eval (eval.c:727)
==2062==    by 0x498B1CB: forcePromise (eval.c:555)
==2062==    by 0x49963AB: FORCE_PROMISE (eval.c:5142)
==2062==    by 0x4996566: getvar (eval.c:5183)
==2062==    by 0x499D1A5: bcEval (eval.c:6873)
==2062==  Uninitialised value was created by a stack allocation
==2062==    at 0x49CEC37: gregexpr_Regexc (grep.c:2369)
==2062== 
==2062== 
==2062== HEAP SUMMARY:
==2062==     in use at exit: 321,320,729 bytes in 55,930 blocks
==2062==   total heap usage: 2,659,604 allocs, 2,603,674 frees, 6,003,459,320 bytes allocated
==2062== 
==2062== 336 bytes in 1 blocks are possibly lost in loss record 152 of 2,701
==2062==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2062==    by 0x40149CA: allocate_dtv (dl-tls.c:286)
==2062==    by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==2062==    by 0x5702322: allocate_stack (allocatestack.c:622)
==2062==    by 0x5702322: pthread_create@@GLIBC_2.2.5 (pthread_create.c:660)
==2062==    by 0x56D0DDA: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2062==    by 0x56C88E0: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2062==    by 0x1543D7C4: LGBM_DatasetCreateFromCSC (c_api.cpp:1286)
==2062==    by 0x1546BEAB: LGBM_DatasetCreateFromCSC_R (lightgbm_R.cpp:91)
==2062==    by 0x4941E2F: R_doDotCall (dotcode.c:634)
==2062==    by 0x494CCC6: do_dotcall (dotcode.c:1281)
==2062==    by 0x499FB01: bcEval (eval.c:7078)
==2062==    by 0x498B67F: Rf_eval (eval.c:727)
==2062==    by 0x498E414: R_execClosure (eval.c:1895)
==2062== 
==2062== LEAK SUMMARY:
==2062==    definitely lost: 0 bytes in 0 blocks
==2062==    indirectly lost: 0 bytes in 0 blocks
==2062==      possibly lost: 336 bytes in 1 blocks
==2062==    still reachable: 321,320,393 bytes in 55,929 blocks
==2062==                       of which reachable via heuristic:
==2062==                         newarray           : 4,264 bytes in 1 blocks
==2062==         suppressed: 0 bytes in 0 blocks
==2062== Reachable blocks (those to which a pointer was found) are not shown.
==2062== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2062== 
==2062== For lists of detected and suppressed errors, rerun with: -s
==2062== ERROR SUMMARY: 7 errors from 2 contexts (suppressed: 0 from 0)

[jameslamb]

@guolinke @StrikerRUS I think this release is ready! All the PRs we wanted to get in have been merged, and the extra CRAN checks for the R package are passing.

Should I submit to CRAN?

[jameslamb]

/gha build r-artifacts

[jameslamb]

https://github.com/microsoft/LightGBM/runs/1512517160?check_suite_focus=true

[jameslamb]

produced this artifact: https://github.com/microsoft/LightGBM/suites/1623533888/artifacts/29854422

I'll wait to submit until @guolinke says it's ok

[jameslamb]

Just submitted to CRAN!

[guolinke]

Thank you! I will draft the new release

[jameslamb]

Thank you! I will draft the new release

ok great, I'll submit to CRAN shortly! They'll send you an email with a link to click. It should go a lot faster this time.

[guolinke]

Do anyone know why v3.1.2 is auto released?

[jameslamb]

@guolinke can you check LightGBM slack? I made a mistake tonight, and explained it there.

[StrikerRUS]

@guolinke I removed 3.1.2 release and tag. Should be good now (it is a Draft that is seen only by maintainers again now).

@jameslamb I've noticed that release drafter re-visites all PRs when triggered by a new commit in master. So there is no problem if you forgot to label PR. Just add a label later after a merge and release drafter will pick it (and categorise in appropriate changes group) after any next PR will be merged.

[jameslamb]

got it, thank you. Sorry again 😬

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.