Repository navigation
[Release cycle] Consider shifting release cycle to align with Python’s annual release schedule #47700
Description
Describe the enhancement requested
Currently, PyArrow/Arrow releases tend to happen around the same time as new Python releases, which creates a timing challenge where PyArrow support for new Python versions arrives after the Python stable release rather than before it.
Current situation
Python releases its ABI-stable release candidate in late July each year, while Arrow’s feature freeze typically occurs in early October. This timing results in PyArrow supporting new Python versions approximately 1 month after Python’s stable release, making PyArrow often the last dependency in the ecosystem to support new Python versions.
Proposal
We could shift the Arrow release cycle to better align with Python’s annual schedule. Specifically, since Python’s ABI-stable RC arrives in late July (for example, Python 3.15 will be July 28, 2026), we could move the Arrow feature freeze to early August (around August 1st), then take the usual time to resolve blockers and release in late August or early September.
This would position PyArrow to support new Python versions approximately 1 month before Python’s stable release instead of 1 month after, ensuring PyArrow wheels are available when or shortly after new Python versions are released.
Benefits and considerations
This change would reduce pressure on downstream packages that depend on PyArrow and provide better alignment with the Python ecosystem’s needs. The timing would become more predictable for Python version support planning.
However, Arrow is a multi-language project, and the release schedule needs to balance requirements across all components including C++, Java, Go, R, and others.
Context
This suggestion originated from discussion in issue #47438 regarding Python 3.14 support.
Component(s)
Packaging, Release, Integration
Activity
paultiq commentedon Oct 6, 2025
In the alternative, if it’s not feasible to shift Arrow’s release cycle to align with Python’s schedule, please consider prioritizing nightly builds during the Python release candidate window*.
Python 3.14’s final release is tomorrow (2025-10-07), after months of RCs, yet PyArrow nightly wheels are unavailable. This creates a major blocker for ecosystem testing, especially for features like free-threading that are officially supported in 3.14.
Having nightly builds available throughout the RC phase would significantly improve downstream testing and reduce the friction currently faced.
raulcd commentedon Oct 10, 2025
Thanks for starting the conversation @EwoutH and @paultiq for your comment. As a maintainer of Arrow, I do understand the problem and would like to work towards a better experience.
I am unsure about the release shifting cycle as there are lots of other implementations using Arrow. When we release we not only releasing Python wheels we also release R, C++, Matlab, Ruby, CGLib, linux packages and others. Accommodating to everyone's release schedule is a difficult task. It would be good to start the conversation on the developer mailing list, @EwoutH do you want to try to drive that? dev@arrow.apache.org
I do think we should do a better job on start the support addition for the following Python versions earlier and trying to add nightly wheels to be ready once we are closer to the release. It would be great to get some help from the community on this. Example of things were we could get help is opening early issues, for example notifying when Python 3.15s RC is available, submitting earlier PRs for adding nightly wheels etcetera this would be highly appreciated.
AlenkaF commentedon Oct 10, 2025
Thank you @raulcd for pointing this out. I agree it would be easier to add nightly wheels close to the Python release with some help from the community. As mentioned, opening early issues and also submitting early PRs would be very, very beneficial and highly appreciated! The initial task is not difficult, one can start by looking at old PRs that do the same. It does take some time to get through failures caused by changes in the dependencies which is always a joint effort.
reneleonhardt commentedon Oct 18, 2025
How can the community contribute a PR introducing Python 3.15 RC if pyarrow isn't allowed to jump ahead of the strict Arrow release cycle?
Could you show us such an old PR when Python 3.14 RC hasn't been built this cycle?
AlenkaF commentedon Oct 20, 2025
Opening early issues and submitting early PRs definitely helps in a way that maintainer's time can then shift to the release itself. That doesn't mean, we will not have to wait for the release and for the wheels to be uploaded, but it does help speed up the process.
github-actions commentedon Oct 20, 2026
This issue has been marked as stale because it has had no activity in the past 365 days. Please remove the stale label or comment below, or this issue will be closed in 14 days. If this improvement is still desired but has no current owner, please add the 'Status: needs champion' label.
EwoutH commentedon Oct 20, 2026
I think this discussion is still relevant. There was almost zero time to test Python 3.15 for downstream dependencies.
paultiq commentedon Oct 20, 2026
From my perspective, things went really well:
Nightly wheels were available since around Python 3.15 rc1, per #48191
And, Arrow shipped wheels to pypi on Oct 9 the same day Python shipped 3.15.0.
What else could the Arrow team have done here?
edgarrmondragon commentedon Oct 20, 2026
I already mentioned this in #48172 (comment), using nightly wheels for testing is extremely easy. Asking the Arrow team to publish wheels to PyPI during the CPython RC phase is perhaps reasonable, but not really necessary.