Python 3.15.0rc2 was released on September 1, 2026 as the final planned release candidate in the series. According to Python.org, it includes around 144 bug fixes, build improvements, and documentation changes from 76 contributors since RC1. Python 3.15.0 final is scheduled for October 1. Most importantly for library maintainers, the team says there will be no further ABI changes from this point and that binary wheels built against Python 3.15 release candidates will work with future Python 3.15 versions.
That creates a useful window to validate compatibility before the final release. RC2 is still a preview and is not recommended for production; the goal now is to test your package, its dependencies, and the artifacts you intend to ship, not to move end users early.
Why RC2 is already a meaningful test of final Python 3.15
During the release-candidate phase, the Python project restricts changes to clear, reviewed bug fixes. The ABI-stability promise removes one specific risk: a binary wheel produced for a 3.15 RC should not become invalid simply because 3.15.0 final was published. For compiled extensions, that makes RC2 especially useful as a build and installation target.
This guarantee does not mean every possible issue is gone. Code fixes can still land before final, and your package may depend on libraries that are not ready yet. The best use of RC2 is therefore to build a reproducible validation process and rerun the same matrix on Python 3.15.0 final when it ships.
1. Add Python 3.15 to CI without dropping versions you already support
Add a Python 3.15 RC2 job alongside the versions your project already supports. The comparison matters: it quickly shows whether a failure appears only on 3.15 or was already present elsewhere.
- Run your normal unit and integration test suite.
- Test the operating systems that are part of your real support policy, especially if you publish binary wheels.
- Start with the same dependency constraints used by your current release; in a separate job, it is useful to test the newest dependency versions too.
- Confirm in the job log that the interpreter actually running is the expected 3.15 RC instead of assuming your CI provider's configuration already points to it.
Triage rule: a failure unique to 3.15 should be classified before it is ignored: a bug in your package, a dependency that is not ready, or a possible Python regression.
2. Separate your package's incompatibility from dependency availability
A test can fail before your code even loads. On a new Python version, a dependency with a native extension may not yet provide a wheel for the new tag, so the installer may fall back to a source build. If that build fails, the installation path is blocked, but the failure is not necessarily in your package's own logic.
| Observed signal | Diagnostic clue | Practical action |
|---|---|---|
| Tests fail only on 3.15 after a normal install | Behavior change, removed API, or an invalid assumption in your code | Reproduce locally and reduce to a minimal case |
| A required dependency will not install | A 3.15 wheel may be missing or the source build may have broken | Record the version, check the upstream project, and decide whether 3.15 support is blocked |
| A native extension builds but cannot be imported | ABI, symbol, tag, or dynamic-loading problem | Test the installed wheel in a clean environment and review C API changes |
| The failure appears only in an optional extra | Compatibility may be limited to that dependency set | Test extras separately and document the scope of support |
3. If you ship native code, treat the build as part of compatibility
Packages with C, C++, Rust, Cython, or other compiled layers need more than a green test suite from the source checkout. The official Python 3.15 “What’s New” document lists C API changes and removals and also introduces a Stable ABI for free-threaded builds called abi3t. That path requires changes and is not mandatory for every extension.
- Build the extension with Python 3.15 RC2 on every platform you intend to support.
- Test importing the compiled module from the installed wheel, not only from the source tree.
- If the project claims support for free-threaded Python, keep a separate job for that mode; if it does not, do not turn a failure there into a blocker for conventional support.
- Review the removed APIs, changed C APIs, and porting guidance in “What’s New in Python 3.15”.
4. Build the RC wheel and install the artifact in an empty environment
The official packaging guide recommends the build package to create source distributions and wheels and considers direct setup.py invocations obsolete for this purpose. The decisive test is not only “my tests pass in the repository” but “the artifact I will distribute installs and works”.
- Create a clean environment with Python 3.15 RC2.
- Install the build tools declared by the project.
- Generate artifacts with python -m build.
- Create a second clean environment and install the wheel produced in dist/.
- Run at least an import smoke test and the essential part of the suite without relying on the repository directory.
This catches issues an editable install can hide, such as missing package files, incomplete metadata, omitted data files, and compiled extensions that fail only when loaded from the wheel.
Python.org explicitly encourages maintainers to publish Python 3.15 wheels during the RC phase so other projects can test their own dependency chains. If your project's release policy allows it, RC2 is already a technically valid target for preparing those wheels.
5. Turn warnings and deprecations into migration work
A suite that passes with dozens of new warnings may still be carrying debt into the next release. Run at least one pass with warnings visible and separate messages emitted by your code from those emitted by dependencies.
- Warnings originating in your package: treat them as compatibility work and fix them before announcing support when they indicate use of an API that is being removed.
- Warnings from required dependencies: track the upstream fix and decide whether the available version prevents 3.15 support.
- Warnings from optional dependencies: record them separately so they do not hide the core package's compatibility status.
- Strict pass: if your suite can handle it, a job with python -W error::DeprecationWarning -m pytest can turn deprecations into failures; triage the results so third-party-only warnings do not block your project automatically.
6. Define blocking criteria before you publish support
| Situation | Block declaring Python 3.15 support? | Recommended interpretation |
|---|---|---|
| A deterministic package test fails only on 3.15 | Yes | Fix it or document an intentional limitation before release |
| The wheel does not build or install on a platform you promise to support | Yes | The distribution artifact is not ready |
| A required dependency does not work on 3.15 | Yes, for the affected scenario | Users cannot install or run the supported stack |
| The failure exists only in an optional extra | It depends on the advertised scope | Separate core support from extra support |
| A free-threaded build fails but your project does not claim that mode | Generally no | Do not confuse an unsupported mode with the conventional interpreter |
| A third-party warning has no immediate functional impact | Not automatically | Track and reassess it; do not hide it |
Final checklist for reaching October 1 with fewer surprises
- Python 3.15 RC2 is present in the CI matrix.
- Core tests and required integrations pass.
- Required dependencies install reproducibly.
- The wheel builds and installs in a clean environment.
- Native extensions are tested on supported platforms.
- New warnings and deprecations are triaged by origin.
- Blocking criteria are recorded before support is announced.
If these items are green, RC2 gives you a strong basis for saying the package is prepared for Python 3.15. ABI stability makes RC-built wheels reusable across the 3.15 series, but it is still prudent to rerun CI as soon as Python 3.15.0 final is published: an ABI guarantee does not eliminate final code fixes or changes in the dependency ecosystem.
