Hi all,
I’m proposing the release schedule for SciPy 1.14.0
below and I’m happy to hear feedback/requests for adjustments if needed.
Date |
Event |
2024-05-25T06:00:00Z |
Branch maintenance/1.14.x |
2024-05-29T06:00:00Z |
SciPy 1.14.0rc1 release |
2024-06-16T06:00:00Z |
SciPy 1.14.0rc2 release (if needed) |
2024-06-25T06:00:00Z |
SciPy 1.14.0 final release |
- Current count of open issues with
1.14.0
milestone on GitHub: 29
- Current count of open PRs with
1.14.0
milestone on GitHub: 38
- I believe the
scipy.special
C++/CUDA “backend” work related to broader community usage/array API extension support may be targeted for this release.
One risk on my end is PTO June 2-8, 2024, but I’ve intentionally shifted the date of the branch cut to 4 days earlier than our last Spring release cycle to reduce the likelihood of a major RC1 delay.
I did hear some informal discussion of NumPy potentially syncing their release cycles to the CPython release cycles to make new feature support (like the nogil/free threading stuff in 3.13
) a bit less complex, but I don’t think they’ve formally switched to doing that. So, the schedule above is still my current plan.
5 Likes
Thanks @tylerjereddy. That should work I think - looking at what’s marked for 1.14.0
there isn’t much that should be considered blocking. I’m like to make sure we get the HiGHS update in, that’s probably the main thing that may still be a fair bit of work but shouldn’t be bumped.
On the topic of time off: I’m on holiday for 2 weeks in May (6th to the 17th) as well. I’ll probably do some light coding, but I will be slow in responding.
One consideration: this year’s Developer Summit is happening June 3 to 5, which would land between rc1 and rc2 in the proposed schedule.
Given the high level of PR activity that we’re likely to see then, what do you think about pushing back the initial branch cut until after your PTO?
Or maybe it’s best to leave the PRs from Seattle for the next point release, to give them more time to settle?
Hey CJ. I am a bit behind schedule with 1.13.1
and 1.14.0
, but I don’t know if we’d want to delay that much. Let’s see if others have opinions. I’d probably want to try to roughly keep to schedule, especially since I’m not there in person this year for the faster reviews/interactions.
Where is the best place to make a PR for additions to the release notes?
The core dev guide says to add to the wiki repo, but the page there doesn’t have all the bullets that appear in the release notes and the text differs too. Plus, maybe I should be making a PR to the 1.14 branch instead of to the wiki now that the rc is released.
For release note suggestions is it best to make a PR to the wiki repo or somewhere else?
Thanks,
Dan
A PR to the maintenance/1.14.x
branch is the way to go now. The wiki is used during the regular part of the development cycle, before there is a release branch.
1 Like