release v4.5.0 #6538
release v4.5.0 #6538
Conversation
|
/gha run r-valgrind Workflow R valgrind tests has been triggered! 🚀 Status: success ✔️. |
python-package/pyproject.toml
Outdated
| @@ -30,7 +30,7 @@ maintainers = [ | |||
| name = "lightgbm" | |||
| readme = "README.rst" | |||
| requires-python = ">=3.7" | |||
| version = "4.4.0.99" | |||
| version = "4.4.0" | |||
There was a problem hiding this comment.
I guess it was a typo.
| version = "4.4.0" | |
| version = "4.5.0" |
There was a problem hiding this comment.
ah!! yes, thank you. Maybe in the future we should have a script that automates these changes, like my colleagues do in the RAPIDS repos: https://github.com/rapidsai/cuml/blob/branch-24.08/ci/release/update-version.sh
There was a problem hiding this comment.
@jameslamb there'd also be https://pypi.org/project/setuptools-scm/ :)
There was a problem hiding this comment.
Very sorry for resolving this without answering you @borchero , that was unintentional.
I'm -1 on using tools like setuptools-scm or versioneer here. In my experience, they introduce much more complexity than they reduce, at least for projects like LightGBM with a linear sequence of releases (no long-term-support branches, backporting, etc.).
For example, they can be the source of hard-to-debug differences between local and CI builds, unless you're diligent about running git fetch upstream --tags or similar regularly.
You might find some of the other discussion in https://discuss.python.org/t/please-make-package-version-go-away/58501 interesting (although I don't agree with the original post... I believe we should continue to support lightgbm.__version__).
Co-authored-by: Nikita Titov <nekit94-08@mail.ru>
I guess you meant |
|
Yes I meant "instead of v4.4.1", just edited it. Sorry for all the typos 😅 |
|
Seems that Azure Pipelines builds are constantly failing for the
For example, the latest one link: https://dev.azure.com/lightgbm-ci/lightgbm-ci/_build/results?buildId=16597&view=results Failing jobs are:
Should these fails be a blockers for this release? |
I'll check again once we're done merging changes here. |
Oh wow, yes I hadn't realized that most I do think we should try to figure this out for the release, but let's not block releasing the R package on them. If we get to, say, July 30 and have still not fixed it, I think we should at least do a release of the R package to CRAN, to avoid it being archived there. Could you document these CI failures in a separate issue, and we could discuss further there? I'm linking this relevant thing I found, that suggests that one issue could be a very long filepath on Windows: sarugaku/shellingham#8. Maybe that could explain the jobs only failing on |
Sure, done!
Absolutely agree! |
|
/gha run r-valgrind Workflow R valgrind tests has been triggered! 🚀 Status: success ✔️. |
jameslamb
requested review from
guolinke,
shiyu1994,
jmoralez and
borchero
as code owners
|
I received the following email from CRAN (Prof Brian Ripley) 3 days ago.
I believe we should release the current state of this PR as v4.5.0 as soon as possible. I want to allow enough time for CRAN to reject the package and for us to put up another submission prior to their summer shutdown. I do not think there are any other open PRs or issues that absolutely MUST be addressed in this release. @guolinke @borchero @jmoralez @shiyu1994 @StrikerRUS could you please review, and approve if you agree? I'd like to get at least 2 approvals (and at least 1 from either @shiyu1994 or @guolinke ) before releasing. |
|
I think we should stop merging any non-trivial PRs before CRAN response. It should help to avoid situation similar to the following one: #4930 in case we will need |
|
Agreed! I'll merge this so we can start the process of releasing. And I'll post follow-up comments here as I've done in previous releases. Thanks for the reviews and help everyone! |
|
Ran the following to create the git checkout master
git pull upstream master
git fetch upstream --tags
git tag -d stable
git push upstream :refs/tags/stable
git tag stable
git tag v4.5.0
git push upstream stable v4.5.0(NOTE: I alias this repo to https://github.com/microsoft/LightGBM/tags 
That triggered an Azure DevOps build which should create the release automatically: https://dev.azure.com/lightgbm-ci/lightgbm-ci/_build/results?buildId=16722&view=results This takes around 90 minutes (because of the QEMU CI job). I'll check back in a few hours and continue the release then. |
|
One test job on the release failed, with what looked like a conda network error. Restarted it. |
done
done! The release is now live: https://github.com/microsoft/LightGBM/releases/tag/v4.5.0 |
|
Submitted to CRAN with this additional note:
|
|
Homebrew has been automatically updated (and bottles have been built): Homebrew/homebrew-core#178449. https://formulae.brew.sh/formula/lightgbm#default:
|
|
Can't find |
|
Previously failing CRAN gcc check is now OK! 🎉 https://cran.r-project.org/web/checks/check_results_lightgbm.html |
This is done.
|
I haven't figured out a good way to make that automatic yet. They're built on GitHub Actions because (at least as of #6391), Azure DevOps didn't have an arm64 runner image. So they have to be manually added to the release. They can be found by clicking "🏠 Summary" on a run of the 
I just manually downloaded that artifact, unzipped it, and uploaded the file to https://github.com/microsoft/LightGBM/releases/tag/v4.5.0. |
This is done: https://test.pypi.org/project/lightgbm/4.5.0/ And installing it (on my M2 Mac) worked fine. pip install \
--no-deps \
-i https://test.pypi.org/simple/ \
lightgbm==4.5.0
python -c "import lightgbm"
python examples/python-guide/sklearn_example.py |
Ah, I see! Thanks for the explanation! * Just checked - still no arm64 macOS runner at Azure 😞 |
this is done: https://pypi.org/project/lightgbm/4.5.0/#files |
done: #6575 |
|
I think we should add one more release TODO item: "update conda-forge version" since @jameslamb is now official lightgbm feedstock's maintainer. |
|
Agreed! I just added it here so we'll remember it when this PR's description is copied into the next release PR. |
put up a PR: #6578 |
done: https://www.nuget.org/packages/LightGBM/4.5.0 That should be fully published some time in the next few hours. 
|
|
With that, I believe this release is complete! Thanks for the help, everyone. Really great having you back to help @StrikerRUS , the throughput in this project was great over the last month. This release covers just 6 weeks of changes, but included 49 commits from 16 different contributors (v4.4.0...v4.5.0). I'm very happy about that! |
|
@jameslamb Thank you very much for your hard work on the release! 💪 |
Release checklist:
Copied from #6439 with a few changes.
deadline
August 3, 2024 (ref: #6522)
before merge
configurefile of R-package:/gha run r-configure.development.modefromunreleasedtoreleasein pkgdown config file.python-package/pyproject.tomlversionadded::annotations (docs on those)config.hhave*New in version {version}*comments added/gha run r-valgrind(docs link)test Python and R packages on arm64 MacItems to be addressed before merging:
after merge
v*tag to triggerGitHubReleaseaction at Azure Pipelines.stabletag at GitHub.code to update tags (click me)
stableversion docs on readthedocs (see [ci] Fix version matching between RTD pages and R-package pages #6673 (comment))release/v{n}.{n}.{n}from RTD versionsafter the release is created by Azure DevOps job
release-drafterto the automatically-created GitHub release, convert it fromDraftto published.code to publish to PyPI (summary)
(
ghis the GitHub CLI, see https://cli.github.com/manual/gh_release_download)Then confirmed that installing the latest wheel works.
pip install -i https://test.pypi.org/simple/ "lightgbm==${NEW_VERSION}" python ./examples/python-guide/logistic_regression.pyThen pushed them to real PyPI.
twine upload \ ./artifacts/*conda-forgerecipecode to open that dev version PR (click me)
Notes for Reviewers
I believe this should be
v4.5.0instead ofv4.4.1because of some small breaking changes:See https://github.com/microsoft/LightGBM/releases.