Python 3.15.0rc2 se publicó el 1 de septiembre de 2026 como el último release candidate planificado de la serie. Según Python.org, incluye alrededor de 144 correcciones de errores, mejoras de build y cambios de documentación aportados por 76 colaboradores desde RC1. Python 3.15.0 final está programado para el 1 de octubre. Lo más importante para quienes mantienen bibliotecas es que el equipo indica que no habrá más cambios de ABI a partir de este punto y que las wheels binarias construidas contra los release candidates de Python 3.15 funcionarán con versiones futuras de Python 3.15.
Eso abre una ventana útil para validar compatibilidad antes de la versión final. RC2 sigue siendo una versión preliminar y no se recomienda para producción; el objetivo ahora es probar tu paquete, sus dependencias y los artefactos que pretendes distribuir, no adelantar la migración de los usuarios finales.
Por qué RC2 ya es una prueba relevante de Python 3.15 final
Durante la fase de release candidate, el proyecto Python restringe los cambios a correcciones claras y revisadas. La promesa de estabilidad de la ABI elimina un riesgo concreto: una wheel binaria producida para un RC de 3.15 no debería quedar inválida simplemente porque se publique 3.15.0 final. Para extensiones compiladas, esto convierte a RC2 en un objetivo especialmente útil de build e instalación.
La garantía no significa que hayan desaparecido todos los problemas posibles. Todavía pueden entrar correcciones de código antes de la versión final y tu paquete puede depender de bibliotecas que aún no estén listas. Por eso, el mejor uso de RC2 es construir una validación reproducible y repetir la misma matriz con Python 3.15.0 final cuando se publique.
1. Añade Python 3.15 a la matriz de CI sin retirar las versiones que ya soportas
Añade un job con Python 3.15 RC2 junto a las versiones que tu proyecto ya soporta. La comparación es importante porque muestra rápidamente si un fallo aparece solo en 3.15 o si ya existía en otras versiones.
- Ejecuta la suite normal de pruebas unitarias y de integración.
- Prueba los sistemas operativos que forman parte del soporte real del paquete, sobre todo si publicas wheels binarias.
- Empieza con los mismos límites de dependencias del release actual; en un job separado, también conviene probar las versiones más recientes de las dependencias.
- Confirma en el log del job que el intérprete ejecutado es realmente el RC esperado de 3.15, en vez de asumir que la configuración del proveedor de CI ya apunta a él.
Criterio de triage: un fallo exclusivo de 3.15 debe clasificarse antes de ignorarlo: defecto de tu paquete, dependencia todavía incompatible o posible regresión de Python.
2. Separa la incompatibilidad de tu paquete de la disponibilidad de las dependencias
Una prueba puede fallar antes incluso de cargar tu código. En una versión nueva de Python, una dependencia con extensión nativa puede no ofrecer todavía una wheel para la nueva etiqueta y el instalador puede intentar compilar desde el código fuente. Si ese build falla, la ruta de instalación queda bloqueada, pero el problema no está necesariamente en la lógica de tu paquete.
| Señal observada | Pista de diagnóstico | Acción práctica |
|---|---|---|
| Las pruebas fallan solo en 3.15 después de una instalación normal | Cambio de comportamiento, API eliminada o suposición incorrecta en tu código | Reproducir localmente y reducir a un caso mínimo |
| Una dependencia obligatoria no se instala | Puede faltar una wheel para 3.15 o puede haberse roto el build desde fuentes | Registrar la versión, revisar el proyecto upstream y decidir si el soporte 3.15 queda bloqueado |
| Una extensión nativa compila, pero no se puede importar | Problema de ABI, símbolo, etiqueta o carga dinámica | Probar la wheel instalada en un entorno limpio y revisar los cambios de la C API |
| El fallo aparece solo en un extra opcional | La compatibilidad puede estar limitada a ese conjunto de dependencias | Probar los extras por separado y documentar el alcance del soporte |
3. Si distribuyes código nativo, trata el build como parte de la compatibilidad
Los paquetes con extensiones en C, C++, Rust, Cython u otras capas compiladas necesitan más que una suite verde desde el checkout de fuentes. El documento oficial “What’s New” de Python 3.15 enumera cambios y eliminaciones de la C API y también introduce una ABI estable para builds free-threaded llamada abi3t. Ese camino exige cambios y no es obligatorio para todas las extensiones.
- Construye la extensión con Python 3.15 RC2 en cada plataforma que pretendes soportar.
- Prueba la importación del módulo compilado desde la wheel instalada, no solo desde el árbol de fuentes.
- Si el proyecto declara soporte para Python free-threaded, mantén un job específico para ese modo; si no lo declara, no conviertas un fallo allí en un bloqueo del soporte convencional.
- Revisa las secciones de APIs eliminadas, C APIs modificadas y recomendaciones de portabilidad en “What’s New in Python 3.15”.
4. Construye la wheel del RC e instala el artefacto en un entorno vacío
La guía oficial de packaging recomienda el paquete build para crear distribuciones de fuente y wheels, y considera obsoletas las invocaciones directas de setup.py para este fin. La prueba decisiva no es solo “mis tests pasan en el repositorio”, sino “el artefacto que voy a distribuir se instala y funciona”.
- Crea un entorno limpio con Python 3.15 RC2.
- Instala las herramientas de build declaradas por el proyecto.
- Genera los artefactos con python -m build.
- Crea un segundo entorno limpio e instala la wheel generada en dist/.
- Ejecuta al menos un smoke test de importación y la parte esencial de la suite sin depender del directorio del repositorio.
Este paso detecta problemas que una instalación editable puede ocultar, como archivos de paquete ausentes, metadatos incompletos, archivos de datos omitidos y extensiones compiladas que solo fallan al cargarse desde la wheel.
Python.org anima explícitamente a los mantenedores a publicar wheels para Python 3.15 durante la fase RC para que otros proyectos puedan probar sus propias cadenas de dependencias. Si la política de releases de tu proyecto lo permite, RC2 ya es un objetivo técnicamente válido para preparar esas wheels.
5. Convierte warnings y deprecaciones en trabajo de migración
Una suite que pasa con decenas de warnings nuevos puede seguir acumulando deuda para la siguiente versión. Ejecuta al menos una pasada con los warnings visibles y separa los mensajes emitidos por tu código de los que provienen de las dependencias.
- Warnings originados en tu paquete: trátalos como trabajo de compatibilidad y corrígelos antes de anunciar soporte cuando indiquen uso de una API que será eliminada.
- Warnings de dependencias obligatorias: sigue la corrección upstream y evalúa si la versión disponible impide el soporte de 3.15.
- Warnings de dependencias opcionales: regístralos por separado para que no oculten el estado de compatibilidad del núcleo.
- Pasada estricta: si tu suite lo permite, un job con python -W error::DeprecationWarning -m pytest puede convertir deprecaciones en fallos; clasifica los resultados para no bloquear automáticamente el proyecto por warnings que pertenecen solo a terceros.
6. Define el criterio de bloqueo antes de publicar soporte
| Situación | ¿Bloquea declarar soporte para 3.15? | Interpretación recomendada |
|---|---|---|
| Una prueba determinista de tu paquete falla solo en 3.15 | Sí | Corregir o documentar una limitación intencional antes del release |
| La wheel no se construye o no se instala en una plataforma que prometes soportar | Sí | El artefacto de distribución aún no está listo |
| Una dependencia obligatoria no funciona en 3.15 | Sí, para el escenario afectado | El usuario no puede instalar o ejecutar la pila soportada |
| El fallo existe solo en un extra opcional | Depende del alcance anunciado | Separa el soporte del núcleo del soporte del extra |
| Falla un build free-threaded, pero tu proyecto no declara ese modo | En general, no | No confundas un modo no soportado con el intérprete convencional |
| Un warning de terceros no tiene impacto funcional inmediato | No automáticamente | Rastrea y reevalúa; no lo ocultes |
Checklist final para llegar al 1 de octubre con menos sorpresas
- Python 3.15 RC2 está presente en la matriz de CI.
- Las pruebas del núcleo y las integraciones obligatorias pasan.
- Las dependencias obligatorias se instalan de forma reproducible.
- La wheel se construye y se instala en un entorno limpio.
- Las extensiones nativas se prueban en las plataformas soportadas.
- Los warnings y deprecaciones nuevos se clasifican por origen.
- Los criterios de bloqueo quedan registrados antes de anunciar soporte.
Si estos puntos están en verde, RC2 ofrece una base sólida para decir que el paquete está preparado para Python 3.15. La estabilidad de la ABI hace que las wheels construidas con el RC puedan reutilizarse dentro de la serie 3.15, pero sigue siendo prudente repetir la CI en cuanto se publique Python 3.15.0 final: la garantía de ABI no elimina correcciones finales de código ni cambios en el ecosistema de dependencias.
