Add `SOURCE_REF_TO_BUILD` rather than manual input field?
@jeremiedbb is already working on this.
Since Sep 16, 2026.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start by reviewing the release procedure and its current manual input handling, then compare the proposed SOURCE_REF_TO_BUILD setting with the linked NumPy and scikit-learn discussions. Determine how a release branch or pull-request merge ref would be represented in the existing YAML and CI logs; done means the release flow no longer requires repeated manual source-reference entry and remains auditable.
Written by the indexing model from the issue text.
Description
I think it's simpler to stay close to numpy while we are still getting to know this new release procedure.
I can see a few advantages to having SOURCE_REF_TO_BUILD in the yaml rather than a manual input field:
- harder to mess up, it's set once in a release branch rather than having to type it manually a few times
- audatibility. Right now nothing in the log is telling you what the input field was. If it's in the repo and an environment variable it's probably in the CI log.
I could not find more details by looking in numpy and numpy-release. The context around not using it in scikit-learn is in https://github.com/scikit-learn/scikit-learn/issues/34320#issuecomment-4752144202.
Also once it is set in a release branch you don't have to think too much about it, rather than typing a few times during the release process.
I think we could also set SOURCE_BUILD_REF to refs/pull/<pr_number>/merge as we did if we want to test on a scikit-learn PR, which did for 1.9.1 since this is part of our release process.
Note that numpy has an issue about this https://github.com/numpy/numpy-release/issues/13, not sure if I am missing something or they haven't realized they can set it to a PR merge ref.
- Dominant language
- Shell
- Stars
- 2
- Forks
- 4
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from scikit-learn/scikit-learn-release
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Copy check_version from numpy to make sure we build from a tag when we upload to PyPIPossibly taken @jeremiedbb claimed this 36 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
scikit-learn/scikit-learn-release#15 · 1 comment ·
-
Create a release branch in the scikit-learn-release repo matching the name of the scikit-learn repoOpen
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
scikit-learn/scikit-learn-release#12 · 1 comment ·
-
Remove chain input from wheels.yml?Possibly taken @jeremiedbb claimed this 36 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
scikit-learn/scikit-learn-release#14 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
scikit-learn/scikit-learn-release#7 · 9 comments ·
All issues in scikit-learn/scikit-learn-release
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MISP/misp-docker#478 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
t4t5/omdrop-owl#83 ·
-
Link Checker ReportOpenautomated issue report
Difficulty 1/5 Under an hour Newbie friendliness 88/100
a2aproject/A2A#2383 ·
Maintainers usually reply within 3 days
-
roadmap-100
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 1 day
-
priority: medium status: needs-decision work-class: scoped
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
melodic-software/claude-code-plugins#9339 · 2 comments ·
Maintainers usually reply within 1 day