Python 3.15 RC2 Released: A Practical Guide to Compatibility Testing and CI Configuration

Python 3.15's final release candidate (Release Candidate 2) has officially arrived, with the stable release expected in October. As Release Manager for Python 3.14 and 3.15, Hugo van Kemenade announced that the codebase has entered a frozen state upon reaching the RC phase. This is a significant signal for both third-party library maintainers and everyday developers across the Python ecosystem.

What the RC Phase Means for Python Developers

A Release Candidate is the final checkpoint before official release. In Python's release process, a new version typically goes through three pre-release phases: alpha (feature exploration, new features allowed), beta (feature freeze, only bug fixes and documentation improvements), and RC (release candidate, only critical bug fixes allowed) before reaching stable release. This process follows PEP 101 (Python Release Process Guide) and version-specific PEP release schedules, ensuring each version undergoes thorough community validation before launch. RC2 means this is the second release candidate, indicating issues found in RC1 required fixes. If RC2 doesn't expose new critical defects during the observation period, it will become the stable release with minimal changes.

Once this phase begins, rules become very strict: only reviewed code changes that clearly fix bugs are allowed to merge into the mainline. In other words, all core features of Python 3.15 are finalized—no new features will be added, and the official focus is entirely on stability and bug fixes.

The Release Manager specifically strongly recommends that maintainers of third-party Python projects begin preparation work for 3.15 at this stage and publish binary wheel packages for Python 3.15 on PyPI. Here's why wheel packages matter: Wheel is Python's standard binary distribution format (defined by PEP 427), with the .whl file extension. Unlike source distributions (sdist), wheel packages are precompiled, so users don't need to compile locally during installation. This is especially important for libraries with C/C++/Rust extension modules (like NumPy, scikit-learn, cryptography)—compiling these from source is not only time-consuming but also requires users to have appropriate compilers and development dependencies installed locally. Wheel filenames encode the target Python version, ABI tag, and OS platform information (e.g., numpy-1.26.0-cp315-cp315-manylinux_2_17_x86_64.whl), so when a new Python version releases, maintainers need to recompile and upload wheels for the new CPython ABI.

Publishing wheels early provides two benefits:

• Your project becomes ready to use out-of-the-box when 3.15.0 officially releases
• You help other libraries that depend on your project complete their own compatibility testing earlier

A key technical commitment: any binary wheel compiled for Python 3.15.0 RC will be compatible with all future Python 3.15.x versions. This commitment is based on Python's intra-version ABI compatibility guarantee—within the same major version series (like 3.15.0 to 3.15.x), CPython's C ABI remains stable and unchanged. This means the build work maintainers invest now won't be wasted; recompilation won't be needed after the stable release.

About the Release Manager Role

Worth noting is that the Release Manager is a critical community governance role in the CPython project. Each Python major version series has a designated Release Manager responsible for the entire version lifecycle from the first alpha to final security updates (typically spanning five years). Release Manager responsibilities include: determining the specific release schedule, approving code changes after entering the code freeze phase, coordinating with infrastructure teams for builds and distribution, and writing release announcements. Hugo van Kemenade serves as Release Manager for both Python 3.14 and 3.15 simultaneously—not uncommon in CPython history. Release Managers are appointed by the Python Steering Council and are typically long-time active core developers.

Why Test Python New Versions During the RC Phase

Prominent developer Simon Willison shared a persuasive personal lesson. Back in 2021, he discovered a bug by running his test suite on Python 3.10—but the problem was, he hadn't tested during the RC phase, and by the time he found it, the bug had already shipped with the stable release.

Since then, I've been watching these RC releases very closely.

This story illustrates the core value of RC testing: before bugs spread with the stable release, the community still has a chance to intercept and fix them. If every project maintainer runs their test suite during the RC phase, the quality of the official Python release will be significantly assured. This exemplifies the "many hands make light work" principle in open-source collaboration—everyone's testing contributes to the entire ecosystem.

In reality, while CPython's test system is extensive (containing tens of thousands of test cases), it cannot possibly cover all third-party library usage scenarios. Many bugs only trigger under specific API call patterns, specific data scales, or specific operating system environments. Third-party project test suites fill this gap—they represent how Python is actually used in real production scenarios and serve as an important complement to CPython's official testing.

Configuring GitHub Actions to Automate Python 3.15 Testing

Although the new RC version wasn't yet directly available on GitHub Actions as of the announcement (developers should watch for actions/python-versions releases), automated pre-release testing can be achieved through test matrix configuration.

GitHub Actions is GitHub's continuous integration/continuous deployment (CI/CD) platform, allowing developers to define automated workflows through YAML configuration files. The "test matrix" (matrix strategy) used here is a core CI concept: it allows a single configuration to run tests in parallel across the Cartesian product of multiple environment dimensions (Python versions, operating systems, dependency versions, etc.). actions/setup-python is a GitHub-official Action responsible for installing specified Python versions on CI runners. It relies on precompiled Python distributions in the actions/python-versions repository—which is why new RC versions need to wait for that repository to update before being usable in CI.

Simply add this to your CI configuration:

strategy:
  matrix:
    python-version: ["3.14", "3.15"]

steps:
  - uses: actions/setup-python@v7
    with:
      python-version: ${{ matrix.python-version }}
      allow-prereleases: true
      check-latest: true

The elegance of this configuration lies in the combination of two flags:

• allow-prereleases: true: Allows setup-python to pull pre-release versions; tests will automatically run against the latest available RC version.
• check-latest: true: Ensures you always use the latest available version. When RC2 goes live, tests automatically switch to RC2; when the stable release ships, they smoothly transition to the stable version.

This "set once, automatically follow" mechanism dramatically reduces the maintenance cost of continuously testing pre-release versions. Developers don't need to manually track each RC iteration—the CI pipeline automatically keeps you at the bleeding edge. For open-source projects in the Python ecosystem, covering pre-release versions in the CI matrix has become a best practice; many well-known projects (like Django, Flask, requests) have adopted similar configuration strategies.

Real Progress on Python 3.15 Ecosystem Compatibility

Simon Willison publicly shared actual test results from several of his projects on Python 3.15, providing a real cross-section of ecosystem compatibility:

Project	Test Status	Notes
Datasette	✅ Passing	—
sqlite-utils	✅ Passing	—
LLM	⚠️ Blocked	scikit-learn hasn't yet provided Python 3.15 wheel packages

This case perfectly reveals the chain dependency characteristic of Python ecosystem compatibility: whether a project can smoothly support a new version often depends not only on its own code but also on the adaptation progress of its dependencies. Libraries like scikit-learn that contain extensive C/C++ extensions and need to compile binary wheels for specific Python versions typically require longer adaptation cycles.

Looking deeper, chain dependency issues are among the most prominent engineering challenges during every Python major version upgrade. Modern Python projects typically have massive dependency trees—a medium-sized web application might directly or indirectly depend on dozens or even hundreds of third-party packages. When Python releases a new version, adaptation must progress layer by layer from the bottom of the dependency chain upward. Take scikit-learn as an example: it depends on bottom-layer scientific computing libraries like NumPy and SciPy, which in turn contain numerous extension modules compiled via Cython or written directly in C/Fortran. Each layer needs to confirm C API/ABI compatibility with the new CPython version, modifying code and recompiling when necessary. If Python 3.15 introduces C API-level changes (such as deprecating certain functions or modifying data structure layouts), the impact amplifies along the dependency chain level by level. This is why the CPython core team has been continuously advancing projects like the "Limited C API" (Limited C API / Stable ABI, PEP 384) and HPy in recent years, aiming to reduce coupling between extension modules and CPython's internal implementation, fundamentally alleviating adaptation pressure from version upgrades.

This also explains from another angle why the Release Manager so strongly emphasizes early wheel publication for 3.15—the earlier foundational libraries at the top of the dependency chain complete adaptation, the smoother the overall migration for downstream projects.

What Different Developer Roles Should Do

The release of Python 3.15 RC2 marks the new version entering its final stabilization sprint. For developers in different roles, there are now clear action items:

Library maintainers: Immediately add Python 3.15 to your CI test matrix, publish wheel packages on PyPI as early as possible, and get ahead in dependency chain adaptation.

Application developers: Run your test suite to verify compatibility, and if you find bugs, report them to CPython officials quickly—this may be the last window for fixes. Worth noting is that CPython uses GitHub Issues as its bug tracking system (repository at github.com/python/cpython); when submitting bug reports, attach a Minimal Reproducible Example whenever possible, which will significantly improve core developers' efficiency in locating and fixing issues.

Regular users: No need to upgrade yet, but you can track 3.15 adaptation status for your commonly used toolchains and plan for the October stable release. You can check adaptation progress through projects' CI status badges or Python version classifiers (Trove Classifiers) on PyPI.

With less than two months until the official Python 3.15.0 release, this window is the golden moment for the entire community to collectively polish the new version's quality.