Ctrl+K

维护者信息#

释放#

本部分是关于准备主要/次要版本、候选版本（RC）或错误修复版本。我们遵循 PEP440 用于版本方案并指示不同类型的版本。我们的惯例是遵循“major.minor.micro”方案，尽管在实践中，主要和次要版本之间没有根本区别，并且微版本是错误修复版本。

我们采用了以下发布时间表：

  • 主要/次要每6个月发布一次，通常在5月和11月。这些版本已编号 X.Y.0 并且之前有一个或多个发布候选项 X.Y.0rcN .

  • 漏洞修复版本在主/次版本之间根据需要进行，并且仅适用于最后一个稳定版本。这些版本已编号 X.Y.Z .

制备

  • 确认标记为里程碑的所有拦截器均已解决，并且标记为里程碑的其他问题可以推迟。

  • 确保为该版本标记的弃用、TEK和TODO已得到处理。

  • 请确保我们的依赖项的最低支持版本已被取消，请参见 提高依赖项的最低版本的指南 有关详细信息

  • 对于主要/次要最终版本，确保 Release Highlights 页面已经作为一个可运行的示例完成，并检查其HTML呈现是否正确。它应该从scikit-learn新版本的新文件中链接。

权限

  • 发布经理必须是 maintainer scikit-learn/scikit-learn存储库的内容，以便能够发布 pypi.org 和 test.pypi.org (via专用Github Action工作流程的手动触发）。

  • 发布经理必须是 maintainer conda-forge/scikit-learn-feedstock存储库的内容，以便能够发布 conda-forge .这可以通过编辑 recipe/meta.yaml 在第一个释放拉取请求中的文件。

参考步骤#

假设我们正在准备发布 1.7.0rc1 .

第一个RC理想地算作 feature freeze .每个即将推出的候选版本和随后的最终版本应仅包括轻微的文档更改和错误修复。应排除任何重大增强或新功能。

  • 创建发布分支 1.7.X 直接在主存储库中，其中 X 实际上是字母X， not a placeholder .的最终和后续错误修复版本的开发 1.7 也应该发生在具有不同标签的这个分支下。

    git fetch upstream main
git checkout upstream/main
git checkout -b 1.7.X
git push --set-upstream upstream 1.7.X

  • 创建针对 1.7.X 分公司将以下发布清单复制到此PR的描述中以跟踪进展。

    * [ ] Update the sklearn dev0 version in main branch
* [ ] Set the version number in the release branch
* [ ] Set an upper bound on build dependencies in the release branch
* [ ] Generate the changelog in the release branch
* [ ] Check that the wheels for the release can be built successfully
* [ ] Merge the PR with `[cd build]` commit message to upload wheels to the staging repo
* [ ] Upload the wheels and source tarball to https://test.pypi.org
* [ ] Create tag on the main repo
* [ ] Confirm bot detected at https://github.com/conda-forge/scikit-learn-feedstock
      and wait for merge
* [ ] Upload the wheels and source tarball to PyPI
* [ ] Announce on mailing list and on social media platforms (LinkedIn, Bluesky, etc.)

  • 创建公关来自 main 和靶向 main 为下一个版本做准备。在此公关中，您需要：

    • 增加Dev0 __version__ 变量 sklearn/__init__.py .这意味着，虽然我们处于发布候选期，但最新的稳定版本落后于 main 分支，而不是一个。

    • 包括一个新的什么是新的文件下， doc/whats_new/ 目录.不要忘记在中添加此新文件的条目 doc/whats_new.rst .

    • 将新文件更改为中新创建的文件 filename 领域 tool.towncrier 科 pyproject.toml .

  • 在发布分支中，更改版本号 __version__ 在 sklearn/__init__.py 到 1.7.0rc1 .

  • 仍然在发布分支中，设置或更新中的构建依赖项的上限 [build-system] 段 pyproject.toml .目标是防止未来向后不兼容的依赖项发布来破坏维护分支中的构建。

    上限应该与最新的已经发布的依赖项次版本相匹配，并且应该允许未来的微型（错误修复）版本。例如，如果numpy 2.2.5是最新版本，则其上限应设置为<2.3.0。

  • 在release分支中，生成传入版本的更新日志，即， doc/whats_new/1.7.rst .在RC期间，我们希望在生成变更日志时保留片段，因为我们将在最终版本中再次生成它，包括其间可能发生的更改：

    towncrier build --keep --version 1.7.0

  • 使用触发车轮制造器 [cd build] commit marker. See also the workflow runs of the wheel builder .

    git commit --allow-empty -m "[cd build] Trigger wheel builder workflow"

    备注

    缩写CD in [cd build] stands for Continuous Delivery 并指的是用于生成发布工件（二进制和源程序包）的自动化。这可以被视为CI的扩展，CI代表 Continuous Integration . GitHub Operations上的CD工作流程还用于为scikit-learn的开发分支自动创建夜间构建和发布包。另见 安装夜间构建 .

  • 一旦所有CD作业在PR中成功完成，将其与 [cd build] marker in the commit message. This time the results will be uploaded to the staging area. You should then be able to upload the generated artifacts (.tar.gz and .whl files) to https://test.pypi.org/ using the "Run workflow" form for the PyPI publishing workflow .

    警告

    这个PR应该与rebase模式合并，而不是通常的壁球模式，因为我们想将历史保留在 1.7.X 分支接近主分支的历史记录，这将有助于未来的错误修复发布。

    此外，如果在合并时，最后一次提交，包含 [cd build] 标记为空，CD作业将不会被触发。在这种情况下，您可以直接使用中的标记推送提交 1.7.X 分支来触发它们。

  • 如果上述步骤顺利，请继续 with caution 为该版本创建新标签。只有在您几乎确定发布已准备好时才应该这样做，因为向主存储库添加新标签可能会触发某些自动化流程。

    git tag -a 1.7.0rc1  # in the 1.7.X branch
git push git@github.com:scikit-learn/scikit-learn.git 1.7.0rc1

    警告

    不要使用github界面来发布发布版本作为创建标签的一种方式，因为即使网站尚未更新并且车轮尚未上传，它也会自动向所有关注回购的用户发送通知。

  • 确认机器人已在conda-forge原料库https://github.com/conda-forge/scikit-learn-feedstock上检测到标签。如果没有，请提交该版本的公关，针对 rc 分公司请确保更新PR，以便与 main 分公司特别是，自上一个版本以来可能添加的回传迁移。

  • 触发 PyPI publishing workflow 再次，但这次是将文物上传到真正的https://pypi.org/。为此，请替换 testpypi 与 pypi 在“运行工作流程”表格中。

    Alternatively ，可以在本地收集生成的二进制轮包和源焦油包并将它们全部上传到PyPI。

    来自当地的文物#

    检查发布标签并运行以下命令。

    rm -r dist
python -m pip install -U wheelhouse_uploader twine
python -m wheelhouse_uploader fetch \
  --version 1.7.0rc1 --local-folder dist scikit-learn \
  https://pypi.anaconda.org/scikit-learn-wheels-staging/simple/scikit-learn/

    这些命令将下载在 staging area on the anaconda.org hosting service 并将它们放在您当地的 ./dist 文件夹.检查 ./dist 文件夹：它应该包含所有轮子以及源焦油 .tar.gz .请确保该文件夹中没有开发者版本或旧版本的scikit-learn软件包。在上传到PyPI之前，您可以测试上传到 test.pypi.org 先

    twine upload --verbose --repository-url https://test.pypi.org/legacy/ dist/*

    然后立即上传所有内容 pypi.org .

    twine upload dist/*

假设我们正在准备发布 1.7.0 .

  • 创建一个新的分支 main 分支，然后从开始交互式重基 1.7.X 要选择需要向后移植的提交：

    git rebase -i upstream/1.7.X

    这将与 git-rebase-todo 包含所有最新提交 main .在这个阶段，您必须至少与其他人执行这种互动重建（以避免忘记某事并避免怀疑）。

    • 不要删除行，而是通过替换来删除提交 pick 与 drop .

    • 为错误修复发布选择的提交包括 generally 前缀为 FIX , CI ，而且 DOC .它们至少应该包括为本版本树立里程碑的合并PR的所有提交。

    • 承诺 drop 对于错误修复版本，包括 generally 前缀为 FEAT , MAINT , ENH ，而且 API .不包含它们的原因是为了防止行为改变（这只应该发生在主要/次要版本中）。

    • 丢弃或选择提交后， do not exit 但粘贴 git-rebase-todo PR中的消息。此文件位于 .git/rebase-merge/git-rebase-todo .

    • 保存并退出以开始交互式重建。必要时解决合并冲突。

  • 创建针对 1.7.X 分公司将以下发布清单复制到此PR的描述中以跟踪进展。

    * [ ] Set the version number in the release branch

* [ ] Generate the changelog in the release branch
* [ ] Check that the wheels for the release can be built successfully
* [ ] Merge the PR with `[cd build]` commit message to upload wheels to the staging repo
* [ ] Upload the wheels and source tarball to https://test.pypi.org
* [ ] Create tag on the main repo
* [ ] Confirm bot detected at https://github.com/conda-forge/scikit-learn-feedstock
      and wait for merge
* [ ] Upload the wheels and source tarball to PyPI
* [ ] Update news and what's new date in main branch
* [ ] Backport news and what's new date in release branch
* [ ] Update symlink for stable in https://github.com/scikit-learn/scikit-learn.github.io
* [ ] Publish to https://github.com/scikit-learn/scikit-learn/releases
* [ ] Announce on mailing list and on social media platforms (LinkedIn, Bluesky, etc.)
* [ ] Update SECURITY.md in main branch

  • 在发布分支中，更改版本号 __version__ 在 sklearn/__init__.py 到 1.7.0 .

  • In the release branch, generate the changelog for the incoming version, i.e., doc/whats_new/1.7.rst. For a non RC release, push a commit where you:

    • 生成变更日志，而不保留片段。

      towncrier build --version 1.7.0

    • 链接发布亮点示例。

    • 添加贡献者名称列表。假设上一个主/次版本中的最后一个版本的标记是 1.6.1 ，然后您可以使用以下命令来检索贡献者姓名列表：

      git shortlog -s 1.6.1.. |
  cut -f2- |
  sort --ignore-case |
  tr "\n" ";" |
  sed "s/;/, /g;s/, $//" |
  fold -s

    然后创建一个针对 main 在那里分支并挑选此提交。

  • 使用触发车轮制造器 [cd build] commit marker. See also the workflow runs of the wheel builder .

    git commit --allow-empty -m "[cd build] Trigger wheel builder workflow"

    备注

    缩写CD in [cd build] stands for Continuous Delivery 并指的是用于生成发布工件（二进制和源程序包）的自动化。这可以被视为CI的扩展，CI代表 Continuous Integration . GitHub Operations上的CD工作流程还用于为scikit-learn的开发分支自动创建夜间构建和发布包。另见 安装夜间构建 .

  • 一旦所有CD作业在PR中成功完成，将其与 [cd build] marker in the commit message. This time the results will be uploaded to the staging area. You should then be able to upload the generated artifacts (.tar.gz and .whl files) to https://test.pypi.org/ using the "Run workflow" form for the PyPI publishing workflow .

    警告

    这个PR应该与rebase模式合并，而不是通常的壁球模式，因为我们想将历史保留在 1.7.X 分支接近主分支的历史记录，这将有助于未来的错误修复发布。

    此外，如果在合并时，最后一次提交，包含 [cd build] 标记为空，CD作业将不会被触发。在这种情况下，您可以直接使用中的标记推送提交 1.7.X 分支来触发它们。

  • 如果上述步骤顺利，请继续 with caution 为该版本创建新标签。只有在您几乎确定发布已准备好时才应该这样做，因为向主存储库添加新标签可能会触发某些自动化流程。

    git tag -a 1.7.0  # in the 1.7.X branch
git push git@github.com:scikit-learn/scikit-learn.git 1.7.0

    警告

    不要使用github界面来发布发布版本作为创建标签的一种方式，因为即使网站尚未更新并且车轮尚未上传，它也会自动向所有关注回购的用户发送通知。

  • 确认机器人已在conda-forge原料库https://github.com/conda-forge/scikit-learn-feedstock上检测到标签。如果没有，请提交该版本的公关，针对 main 分公司

  • 触发 PyPI publishing workflow 再次，但这次是将文物上传到真正的https://pypi.org/。为此，请替换 testpypi 与 pypi 在“运行工作流程”表格中。

    Alternatively ，可以在本地收集生成的二进制轮包和源焦油包并将它们全部上传到PyPI。

    来自当地的文物#

    检查发布标签并运行以下命令。

    rm -r dist
python -m pip install -U wheelhouse_uploader twine
python -m wheelhouse_uploader fetch \
  --version 1.7.0 --local-folder dist scikit-learn \
  https://pypi.anaconda.org/scikit-learn-wheels-staging/simple/scikit-learn/

    这些命令将下载在 staging area on the anaconda.org hosting service 并将它们放在您当地的 ./dist 文件夹.检查 ./dist 文件夹：它应该包含所有轮子以及源焦油 .tar.gz .请确保该文件夹中没有开发者版本或旧版本的scikit-learn软件包。在上传到PyPI之前，您可以测试上传到 test.pypi.org 先

    twine upload --verbose --repository-url https://test.pypi.org/legacy/ dist/*

    然后立即上传所有内容 pypi.org .

    twine upload dist/*

  • 在 main 分支，编辑 doc/templates/index.html 更改着陆页中的“新闻”部分，以及发布的月份。不要忘记删除旧条目（两年前或三个版本前）并更新“持续开发”条目。然后在release分支中选择它。

  • 更新符号链接 stable 和 latestStable 变量 versionwarning.js 请访问https://github.com/scikit-learn/scikit-learn.github.io。

    cd /tmp
git clone --depth 1 --no-checkout git@github.com:scikit-learn/scikit-learn.github.io.git
cd scikit-learn.github.io
echo stable > .git/info/sparse-checkout
git checkout main
rm stable
ln -s 1.7 stable
sed -i "s/latestStable = '.*/latestStable = '1.7';/" versionwarning.js
git add stable versionwarning.js
git commit -m "Update stable to point to 1.7"
git push origin main

  • 在https://github.com/scikit-learn/scikit-learn/releases上发布该版本，并在邮件列表和社交网络上宣布。请记住在发布说明中添加一个指向更新日志的链接。理想情况下，只有在PyPI和conda-forge上都有软件包并且网站是最新的时候才执行这个步骤。

  • 更新 SECURITY.md 以反映最新支持的版本 1.7.0 .

假设我们正在准备发布 1.6.2 .

  • 创建一个新的分支 main 分支，然后从开始交互式重基 1.6.X 要选择需要向后移植的提交：

    git rebase -i upstream/1.6.X

    这将与 git-rebase-todo 包含所有最新提交 main .在这个阶段，您必须至少与其他人执行这种互动重建（以避免忘记某事并避免怀疑）。

    • 不要删除行，而是通过替换来删除提交 pick 与 drop .

    • 为错误修复发布选择的提交包括 generally 前缀为 FIX , CI ，而且 DOC .它们至少应该包括为本版本树立里程碑的合并PR的所有提交。

    • 承诺 drop 对于错误修复版本，包括 generally 前缀为 FEAT , MAINT , ENH ，而且 API .不包含它们的原因是为了防止行为改变（这只应该发生在主要/次要版本中）。

    • 丢弃或选择提交后， do not exit 但粘贴 git-rebase-todo PR中的消息。此文件位于 .git/rebase-merge/git-rebase-todo .

    • 保存并退出以开始交互式重建。必要时解决合并冲突。

  • 创建针对 1.6.X 分公司将以下发布清单复制到此PR的描述中以跟踪进展。

    * [ ] Set the version number in the release branch

* [ ] Generate the changelog in the release branch
* [ ] Check that the wheels for the release can be built successfully
* [ ] Merge the PR with `[cd build]` commit message to upload wheels to the staging repo
* [ ] Upload the wheels and source tarball to https://test.pypi.org
* [ ] Create tag on the main repo
* [ ] Confirm bot detected at https://github.com/conda-forge/scikit-learn-feedstock
      and wait for merge
* [ ] Upload the wheels and source tarball to PyPI
* [ ] Update news and what's new date in main branch
* [ ] Backport news and what's new date in release branch
* [ ] Publish to https://github.com/scikit-learn/scikit-learn/releases
* [ ] Announce on mailing list and on social media platforms (LinkedIn, Bluesky, etc.)
* [ ] Update SECURITY.md in main branch

  • 在发布分支中，更改版本号 __version__ 在 sklearn/__init__.py 到 1.6.2 .

  • In the release branch, generate the changelog for the incoming version, i.e., doc/whats_new/1.6.rst. For a non RC release, push a commit where you:

    • 生成变更日志，而不保留片段。

      towncrier build --version 1.6.2

    • 添加贡献者名称列表。假设上一个主/次版本中的最后一个版本的标记是 1.7.0 ，然后您可以使用以下命令来检索贡献者姓名列表：

      git shortlog -s 1.7.0.. |
  cut -f2- |
  sort --ignore-case |
  tr "\n" ";" |
  sed "s/;/, /g;s/, $//" |
  fold -s

    然后创建一个针对 main 在那里分支并挑选此提交。

  • 使用触发车轮制造器 [cd build] commit marker. See also the workflow runs of the wheel builder .

    git commit --allow-empty -m "[cd build] Trigger wheel builder workflow"

    备注

    缩写CD in [cd build] stands for Continuous Delivery 并指的是用于生成发布工件（二进制和源程序包）的自动化。这可以被视为CI的扩展，CI代表 Continuous Integration . GitHub Operations上的CD工作流程还用于为scikit-learn的开发分支自动创建夜间构建和发布包。另见 安装夜间构建 .

  • 一旦所有CD作业在PR中成功完成，将其与 [cd build] marker in the commit message. This time the results will be uploaded to the staging area. You should then be able to upload the generated artifacts (.tar.gz and .whl files) to https://test.pypi.org/ using the "Run workflow" form for the PyPI publishing workflow .

    警告

    这个PR应该与rebase模式合并，而不是通常的壁球模式，因为我们想将历史保留在 1.6.X 分支接近主分支的历史记录，这将有助于未来的错误修复发布。

    此外，如果在合并时，最后一次提交，包含 [cd build] 标记为空，CD作业将不会被触发。在这种情况下，您可以直接使用中的标记推送提交 1.6.X 分支来触发它们。

  • 如果上述步骤顺利，请继续 with caution 为该版本创建新标签。只有在您几乎确定发布已准备好时才应该这样做，因为向主存储库添加新标签可能会触发某些自动化流程。

    git tag -a 1.6.2  # in the 1.6.X branch
git push git@github.com:scikit-learn/scikit-learn.git 1.6.2

    警告

    不要使用github界面来发布发布版本作为创建标签的一种方式，因为即使网站尚未更新并且车轮尚未上传，它也会自动向所有关注回购的用户发送通知。

  • 确认机器人已在conda-forge原料库https://github.com/conda-forge/scikit-learn-feedstock上检测到标签。如果没有，请提交该版本的公关，针对 main 分公司

  • 触发 PyPI publishing workflow 再次，但这次是将文物上传到真正的https://pypi.org/。为此，请替换 testpypi 与 pypi 在“运行工作流程”表格中。

    Alternatively ，可以在本地收集生成的二进制轮包和源焦油包并将它们全部上传到PyPI。

    来自当地的文物#

    检查发布标签并运行以下命令。

    rm -r dist
python -m pip install -U wheelhouse_uploader twine
python -m wheelhouse_uploader fetch \
  --version 1.6.2 --local-folder dist scikit-learn \
  https://pypi.anaconda.org/scikit-learn-wheels-staging/simple/scikit-learn/

    这些命令将下载在 staging area on the anaconda.org hosting service 并将它们放在您当地的 ./dist 文件夹.检查 ./dist 文件夹：它应该包含所有轮子以及源焦油 .tar.gz .请确保该文件夹中没有开发者版本或旧版本的scikit-learn软件包。在上传到PyPI之前，您可以测试上传到 test.pypi.org 先

    twine upload --verbose --repository-url https://test.pypi.org/legacy/ dist/*

    然后立即上传所有内容 pypi.org .

    twine upload dist/*

  • 在 main 分支，编辑 doc/templates/index.html 更改着陆页中的“新闻”部分，以及发布的月份。然后在release分支中选择它。

  • 在https://github.com/scikit-learn/scikit-learn/releases上发布该版本，并在邮件列表和社交网络上宣布。请记住在发布说明中添加一个指向更新日志的链接。理想情况下，只有在PyPI和conda-forge上都有软件包并且网站是最新的时候才执行这个步骤。

  • 更新 SECURITY.md 以反映最新支持的版本 1.6.2 .

更新作者列表#

本节是关于更新 scikit-learn背后的人 .首先创建一个 classic token on GitHub 与 read:org 许可引然后运行以下脚本并在出现提示时输入令牌：

cd build_tools
make authors  # Enter the token when prompted

提高依赖项的最低版本的指南#

  • minimum Python version ：在scikit-learn发布时 (X.Y.0 ），我们放弃了初始发布日期超过4年前的Python版本。换句话说，我们的最低Python版本在3到4岁之间。

  • compiled dependencies （numpy、scipy，以及已编译的可选依赖项（pandas、matplotlib、pyamg、pillow、.）：我们采用最古老的次要版本 (X.Y.0 ）它有适合我们最低Python版本的轮子。在实践中，这意味着我们最低支持的版本大约是3年，也许更少一点。

  • pure Python dependencies （jobib，threadpoolctl）：在scikit-learn发布时，我们最低支持的版本是最新的次要版本 (X.Y.0 ）至少2岁了。

  • 在某些边缘情况下，我们可能会决定不那么保守。这些边缘案例包括：我们的一个依赖项中的安全错误修复或我们的一个依赖项中的关键错误修复使得在维护方面支持它的成本太高。

maint_tools/bump-dependencies-versions.py 实现这些规则，并可用于给出新的最小依赖项版本。它将预期的scikit-learn发布日期作为输入，例如：

python maint_tools/bump-dependencies-versions.py 2025-12-01

合并拉取请求#

当PR在GitHub上合并时，各个提交将被挤压。合并前：

  • 如有必要，可以编辑生成的提交标题。请注意，这将默认重命名PR标题。

  • 包含所有提交标题的详细描述可以编辑或删除。

  • 对于具有多个代码贡献者的PR，必须小心保存 Co-authored-by: name <name@example.com> tags in the detailed description. This will mark the PR as having multiple co-authors .代码贡献是否足以值得共同创作由维护者自行决定，与What ' s new条目相同。

的 scikit-learn.org 网站#

scikit-learn网站（https：scikit-learn.org）托管在GitHub上，但很少应该通过推送到https://github.com/scikit-learn/scikit-learn.github.io存储库来手动更新。大多数更新都可以通过推到来进行 main （对于 /dev ）或发布分支 A.B.X ，Circle CI会自动从中构建和上传文档。

实验性功能#

的 sklearn.experimental 模块是在0.21中引入的，包含实验性的特性和估计器，这些特性和估计器可能会在没有弃用周期的情况下发生变化。

要创建实验模块，请参阅 enable_halving_search_cv.py ，或者 enable_iterative_imputer.py .

备注

这些都是永久链接，如0.24中所示，其中这些估计器仍然是实验性的。它们在阅读时可能是稳定的，因此是永久链接。有关从实验性过渡到稳定性的说明，请参阅下文。

请注意，公共导入路径必须是公共子包（例如 sklearn/ensemble 或 sklearn/impute ），不仅仅是一个 .py module.此外，导入的（私有）实验功能必须位于公共子包的子模块/子包中，例如 sklearn/ensemble/_hist_gradient_boosting/ 或 sklearn/impute/_iterative.py .这是必要的，以便泡菜在未来不再实验性的情况下仍然可以使用。

避免类型检查（例如 mypy) errors a direct import of experimental estimators should be done in the parent module, protected by the if typing.TYPE_CHECKING check. See sklearn/ensemble/__init__.py ，或者 sklearn/impute/__init__.py 举个例子。请在中的测试之后编写基本测试 test_enable_hist_gradient_boosting.py .

确保您编写的每个面向用户的代码都明确提及该功能是实验性的，并添加 # noqa 避免PEP 8相关警告的评论：：

# To use this experimental feature, we need to explicitly ask for it
from sklearn.experimental import enable_iterative_imputer  # noqa
from sklearn.impute import IterativeImputer

For the docs to render properly, please also import enable_my_experimental_feature in doc/conf.py, otherwise sphinx will not be able to detect and import the corresponding modules. Note that using from sklearn.experimental import * does not work.

备注

一些实验课程和功能可能不包含在 sklearn.experimental 模块，例如， sklearn.datasets.fetch_openml .

功能稳定后，删除所有出现的 enable_my_experimental_feature in the scikit-learn code base and make the enable_my_experimental_feature a no-op that just raises a warning, as in enable_hist_gradient_boosting.py .该文件应该无限期保留在那里，因为我们不想破坏用户的代码;我们只是通过警告激励他们删除该导入。另请记住相应更新测试，请参阅 test_enable_hist_gradient_boosting.py .

On this page