Python 3.15 RC1: що перевірити авторам бібліотек до фінального релізу

Python 3.15.0rc1 — етап, на якому ABI гілки вже зафіксований, а екосистема має перевірити бібліотеки до фінального релізу. RC не призначений для безумовної заміни production runtime, зате це найкращий момент знайти несумісність у C extensions, build backend, import behavior і packaging.

Завдання RC — перевірити весь ланцюг

Unit tests чистого Python-коду — лише початок. Додайте 3.15 до CI, зберіть sdist і wheels, встановіть їх у чисте середовище та запустіть integration tests. Перевірте Linux, macOS і Windows, а для платформ із різними architectures — кожну підтримувану комбінацію.

Бінарні wheels, створені для RC після фіксації ABI, мають бути основою раннього тестування фінальної гілки, але їх усе одно потрібно збирати вашим звичайним release process. Переконайтеся, що auditwheel/delocate, manylinux/musllinux tags і signing працюють без ручних винятків.

C API, Cython і PyO3 мають найвищий ризик

Проєкти з нативними розширеннями залежать від compiler, headers, limited API, binding generator і зовнішніх бібліотек. Зберіть їх без використання старих object files. Увімкніть warnings і перевірте deprecation, reference counting, subinterpreters та free-threaded build, якщо його заявлено в підтримці.

Для PyO3/Rust зафіксуйте сумісну версію binding і Rust toolchain. Успішний import не замінює тесту пам’яті, конкуренції та винятків на межі мов. Якщо бібліотека не готова до free-threaded режиму, краще явно це задокументувати, ніж мовчки створити нестабільний wheel.

Нові мовні можливості мають побічні ефекти

Зміни імпортів, UTF‑8 defaults, стандартної бібліотеки, JIT або вбудованих типів можуть впливати на startup, порядок реєстрації plugin і серіалізацію. Перевіряйте CLI, web workers, multiprocessing, locale, кодування файлів та reload у dev server. Окремо знімайте всі DeprecationWarning у власному коді й залежностях.

Якщо бібліотека використовує introspection або monkey patching, додайте golden tests для публічного API. Такі проєкти частіше залежать від деталей реалізації, які звичайний type checker не бачить.

Чекліст мейнтейнера

1. Додати 3.15 RC до test matrix без вилучення найстарішої підтримуваної версії.
2. Побудувати sdist/wheels у чистому release environment і перевірити їх встановлення.
3. Пройти native extensions, free-threaded variant і всі optional dependencies.
4. Виміряти startup, memory і критичні benchmarks, пояснивши значні відхилення.
5. Опублікувати prerelease package та запросити користувачів до тестування.
6. Повідомити про регресію до фінального релізу, коли виправлення ще можна включити.

Production runtime до фінального 3.15 краще не перемикати, якщо немає окремого контрольованого експерименту. Натомість CI із дозволом failure не повинен залишатися назавжди необов’язковим: до release candidate 2 команда має визначити блокувальні проблеми. Основи екосистеми описані в путівнику мовою Python, а оптимізацію запуску — у статті про startup Python-застосунків.

Як оформити підтримку Python 3.15

Оновіть classifiers, requires-python, CI matrix і документацію тільки після реального проходження тестів. Не заявляйте підтримку на підставі одного імпорту. Для optional features перевірте кожен набір extras, бо основний wheel може працювати, а рідкісна залежність — ні.

Якщо проблема у сторонньому пакеті, створіть мінімальний reproduction і повідомте upstream до фінального релізу. Тимчасовий upper bound має посилатися на issue та мати умову видалення. Мовчазне виключення Python 3.15 залишить користувача без пояснення.

Після виходу фінальної версії перебудуйте wheels у release environment, повторіть smoke install і лише тоді змініть production matrix. RC-тестування скорочує цей шлях, але не скасовує фінальної перевірки.

Першоджерело: офіційний реліз Python 3.15.0rc1.