F45 Change Proposal: Python3.15 [SystemWide]

Project Discussion Change Proposals
, ,
1

Python3.15

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Update the Python stack in Fedora from Python 3.14 to Python 3.15, the newest major release of the Python programming language.

Owner :open_book:

Detailed Description :open_book:

We would like to upgrade Python to 3.15 in Fedora 45 thus we are proposing this plan early.

See the upstream notes at [What’s new in Python 3.15 — Python 3.15.0a1 documentation What’s new in 3.15].

=== Important dates and plan ===

  • 2025-05-07: Python 3.15 development begins
  • 2025-10-14: Python 3.15.0 alpha 1
    ** Package it as {{package|python3.15}} for testing purposes
    ** Start the bootstrap procedure in Copr
    ** Do a mass rebuild against every future release in Copr
  • 2025-11-18: Python 3.15.0 alpha 2
  • 2025-12-16: Python 3.15.0 alpha 3
  • 2026-01-13: Python 3.15.0 alpha 4
  • 2026-02-03: Branch Fedora 44, Rawhide becomes future Fedora 45
    ** The earliest point when we can start rebuilding in Koji side-tag
  • 2026-02-10: Python 3.15.0 alpha 5
  • 2026-03-10: Python 3.15.0 alpha 6
  • 2026-04-07: Python 3.15.0 alpha 7
  • 2026-05-05: Python 3.15.0 beta 1
    ** No new features beyond this point
  • 2026-05-26: Python 3.15.0 beta 2
    ** The ideal point when we can start rebuilding in Koji
  • 2026-06-02: Expected side tag-merge (optimistic)
  • 2026-06-16: Python 3.15.0 beta 3
  • 2026-06-23: Expected side tag-merge (realistic)
  • 2026-06-30: Expected side tag-merge (pessimistic)
  • 2026-07-14: Python 3.15.0 beta 4
  • 2026-07-22: Fedora 45 Mass Rebuild
    ** The mass rebuild happens with the fourth or third beta. We might need to rebuild Python packages later in exceptional case.
    ** If the Koji side-tag is not merged yet at this point, we defer the change to Fedora 46.
  • 2026-07-28: Python 3.15.0 candidate 1
    ** This serves as “final” for our purposes.
  • 2026-08-11: Branch Fedora 45, Rawhide becomes future Fedora 46
  • 2026-08-11: Fedora 45 Change Checkpoint: Completion deadline (testable)
  • 2026-08-25: Fedora Beta Freeze
    ** If rebuild with 3.15.0rc1 is needed, we should strive to do it before the freeze - there is a window of 4 weeks.
  • 2026-09-01: Python 3.15.0 candidate 2
  • 2026-09-15: Fedora 45 Beta Release (Preferred Target)
    ** Beta will likely be released with 3.15.0rc2.
  • 2026-10-01: Python 3.15.0 final
  • 2026-10-06: Fedora 45 Final Freeze
    ** If the 3.15.0 final release is delayed, we’ll update it using a freeze exception.
  • 2026-10-20: Fedora 45 Final Target date #1
  • 2026-10-27: Fedora 45 Final Target date #2

(From [PEP 790 – Python 3.15 Release Schedule | peps.python.org Python 3.15 Release Schedule] and [Fedora Linux 45 Schedule: Key Fedora 45 Release Schedule].)

The schedule might appear somewhat tight for Fedora 45, but Python’s [Making sure you're not a bot! annual release cycle was adapted for Fedora] and this worked fine since Python 3.9 and Fedora 33. It is now common that Python is upgraded on a similar schedule in every odd-numbered Fedora release.

Note that upstream’s “release candidates” are frozen except for blocker bugs. Since we can and will backport blocker fixes between Fedora and upstream, we essentially treat the Release Candidate as the final release.

Feedback :open_book:

Benefit to Fedora :open_book:

Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.15.

There’s also a benefit to the larger Python ecosystem: by building Fedora’s packages against 3.15 while it’s still in development, we can catch critical bugs before the final 3.15.0 release.

Scope :open_book:

We will coordinate the work in a side tag and merge when ready.

  • Proposal owners:
    *# Introduce {{package|python3.15}} for all Fedoras
    *# Prepare stuff in Copr as explained in description.
    *# Update {{package|python-rpm-macros}} so {{package|python3.15}} builds {{package|python3}}
    *# Build {{package|python3.15}} as the main Python
    *# Mass rebuild all the packages that runtime require python(abi) = 3.14 and/or libpython3.14.so.1.0 (~3900 known packages in October 2025)
    *# Build {{package|python3.14}} as a non-main Python

  • Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: [What’s new in Python 3.15 — Python 3.15.0a1 documentation Porting to Python 3.15]. The python-maint team will be available to help with fixing issues.

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact :open_book:

All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.14 is forward compatible with Python 3.15.
Packages that fail to install because they failed to rebuild with Python 3.15 will be retired at Final Freeze unless they have a proposed Freeze Exception.

Early Testing (Optional) :open_book:

How To Test :open_book:

Interested testers do not need special hardware. If you have a favorite Python 3 script, module, or application, please test it with Python 3.15 and verify that it still works as you would expect. If the application you are testing does not require any other modules, you can test it using {{package|python3.15}} even before this change is implemented, in Fedora 41, 42, 43 or 44.

In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3.15 version of the python3 rpm. That rpm will shortly be available in Copr, along with all other python packages that build successfully with python 3.15. See https://copr.fedorainfracloud.org/coprs/g/python/python3.15/ for detailed instructions on how to enable Python 3.15 Copr for mock.

Once the change is in place, test if your favorite Python apps are working as they were before. File bugs if they don’t.

User Experience :open_book:

Regular distro users shouldn’t notice any change in system behavior other than the Python 3 interpreter will be in version 3.15.

Dependencies :open_book:

~4300 packages depend on Python 3 and ~3900 packages need rebuilding when Python is upgraded. See scope section.

Contingency Plan :open_book:

  • Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.14 version (never needed before)

Documentation :open_book:

[PEP 790 – Python 3.15 Release Schedule | peps.python.org Python 3.15 Release Schedule]

[What’s new in Python 3.15 — Python 3.15.0a1 documentation What’s new in 3.15]

Release Notes :open_book:

Last edited by @alking 2025-10-16T19:40:30Z

Last edited by @alking 2025-10-16T19:40:30Z

2 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Let me just say this is an exemplary change, planned well in advance and with well-defined plan. Kudos to our Pythonistas.

3 Likes
4

Not as an objection, but what is being done to (try to) prevent the situation that happened in 3.14 in which two additional partial mass-rebuilds were necessary for late bytecode format changes? At a minimum, this is a risk that should be documented in the change proposal.

5

There is not much that we (Fedora) can do.

But note that those were no “language” changes per se: python packages which had been adapted to python 3.14 would compile unchanged after the bytecode change. Any issues which came up came up because other things had changed meanwhile (if I remember correctly) and would have come up also for any rebuild without a python bytecode change.

That is a general challenge with our mass rebuilds: if it succeeds it is really the statement:

  • given the current buildroot, all packages can be rebuilt

That statement is voided by the merge already since it changes the buildroot. In other words: a mass rebuild+merge is not even guaranteed to be idempotent. Packages may FTBFS after the merge. Mass rebuilt packages may fail to build in the new (mass rebuilt+merged) buildroot.

Additional mass rebuilds expose those deficiences. But the real cause are late language/api/toolchain changes (sneaking into the rebuild) which I’m not going to name here :wink:

I know you know all this, but it outlines the positive effects of those additional rebuilds. In an ideal world, everything would have stabilised well ahead.

6

Not much we can do here. What we should do — elsewhere — is to keep working
on keeping our packages buildable at all times. The situation where packages
routinely FTBFS and need manual poking to rebuild every time creates multiple
problems:

  • in the mass rebuild
  • for occasional “mini mass rebuilds” like the Python one
  • for people working on various cleanups
  • anyone trying to do an SONAME version bump quickly
  • and even for the maintainers of those packages, because every rebuild
    becomes a potential failure point…

We have koschei and CI and we if we improved our game here, development
of Fedora would be smoother.

1 Like
7

Packages that chronically FTBFS also make it more time-consuming to conduct COPR impact checks ahead of potentially-disruptive udpdates. When you are checking an update for a package with, say, 100 reverse dependencies, and 20 of them have pre-existing FTBFS issues, the small amount of time that it takes to check each of them really starts to add up.

(The maintainers of these packages are not always to blame. Packages with large dependency trees and comprehensive test suites have much more exposure to the consequences of external changes.)

1 Like
8

I agree that overall, having always-buildable packages in Fedora would be great. During our two additional mass rebuilds for Python 3.14, the absolute majority of the packages were successfully built. Overall, I think that the mass rebuilds were quite smooth. Sure, dozens of packages did not build, a couple of packages were stuck on broken/unstable gating, and several packages were only built in Rawhide as their f43 branch was already diverged. However, 3736 packages are done, only 65 TODO. Considering the impact of missed rebuild (slower import times, but nothing is broken) we don’t aim for 100% completeness anyway.

The current proposal already says:

We might need to rebuild Python packages later in exceptional case.

I don’t mind expanding this a bit and explaining what might happen in case of ABI break and in case of pyc magic bump. I concur that this situation is not well-documented in the proposal.

As for what we can do to prevent this from happening upstream, indeed, not much. Downstream, we might collectively consider this dangerous enough to postpone the upgrade for half a year (I would disagree with that, but others might want to do that).

With @ksurma and @encukou we plan to brainstorm some ideas about allowing our Python to read older bytecode, when some circumstances are met. That might allow us to limit the scope of the needed rebuild for packages that actually are affected by the bytecode change.

If we cannot prevent this from happening, at least we might see how to make it easier for us. For example, determining whether a package needs a bytecode rebuild is currently nontrivial. One must examine the root.log or the actual bytecode from the RPMs, or else we guess it based on the date and time of the build. I was considering whether we can generate RPM metadata (e.g. as Suggests: python(magic) = 3626) for this, so we could easily repoquery this information.

1 Like
9

Great writeup/plan. Kudos!

10

I don’t think the bytecode-rebuild improvements should block this.

This was announced 4 weeks ago. Let’s move this to FESCo?