O Python 3.15.0rc2 foi lançado em 1º de setembro de 2026 como o último release candidate planejado da série. Segundo o Python.org, ele reúne cerca de 144 correções de bugs, melhorias de build e mudanças de documentação feitas por 76 contribuidores desde o RC1. O 3.15.0 final está programado para 1º de outubro. Mais importante para quem mantém bibliotecas: a equipe informa que não haverá novas mudanças de ABI a partir deste ponto e que wheels binárias construídas contra os release candidates do Python 3.15 funcionarão com versões futuras do 3.15.
Isso cria uma janela útil para validar compatibilidade antes do lançamento final. O RC2 continua sendo uma prévia e não é recomendado para produção; o objetivo agora é testar o seu pacote, suas dependências e os artefatos que você pretende distribuir, não migrar usuários finais antecipadamente.
Por que o RC2 já é um teste relevante do Python 3.15 final
Na fase de release candidate, o projeto Python restringe mudanças a correções claras e revisadas. A promessa de estabilidade da ABI reduz um risco específico: uma wheel binária produzida para um RC do 3.15 não deve se tornar inválida apenas porque o 3.15.0 final foi publicado. Para extensões compiladas, isso torna o RC2 especialmente valioso como alvo de build e instalação.
Essa garantia não significa que todos os problemas possíveis desapareceram. Ainda pode haver correções de código antes do final, e seu pacote pode depender de bibliotecas que ainda não estejam prontas. Por isso, o melhor uso do RC2 é montar uma validação reproduzível e repetir a matriz no 3.15.0 final quando ele sair.
1. Adicione o Python 3.15 à matriz de CI sem remover as versões já suportadas
Inclua um job com Python 3.15 RC2 ao lado das versões que o projeto já suporta. A comparação é importante: ela mostra rapidamente se uma falha aparece apenas no 3.15 ou se já existia em outras versões.
- Rode a suíte normal de testes unitários e de integração.
- Teste nos sistemas operacionais que fazem parte do suporte real do pacote, sobretudo se você publica wheels binárias.
- Use primeiro os mesmos limites de dependências do release atual; em um job separado, vale testar também as versões mais recentes das dependências.
- Confirme no log do job que o interpretador executado é o 3.15 RC esperado, em vez de presumir que a configuração do provedor de CI já aponta para ele.
Critério de triagem: uma falha exclusiva do 3.15 deve ser classificada antes de ser ignorada: defeito no seu pacote, dependência ainda incompatível ou possível regressão do próprio Python.
2. Separe incompatibilidade do seu pacote de indisponibilidade das dependências
Um teste pode falhar antes mesmo de carregar seu código. Em versões novas do Python, uma dependência com extensão nativa pode ainda não oferecer wheel para a nova tag e o instalador pode tentar compilar a partir do código-fonte. Se essa compilação falhar, o bloqueio está no caminho de instalação, mas não necessariamente na lógica do seu pacote.
| Sinal observado | Pista de diagnóstico | Ação prática |
|---|---|---|
| Testes falham só no 3.15 após instalação normal | Mudança de comportamento, API removida ou hipótese incorreta no seu código | Reproduzir localmente e reduzir para um caso mínimo |
| Uma dependência obrigatória não instala | Wheel do 3.15 pode ainda não existir ou o build de fonte pode ter quebrado | Registrar a versão, verificar o projeto upstream e decidir se o suporte 3.15 fica bloqueado |
| Uma extensão nativa compila, mas não importa | Problema de ABI, símbolo, tag ou carregamento dinâmico | Testar a wheel instalada em ambiente limpo e revisar as mudanças de C API |
| Falha aparece apenas em um extra opcional | Compatibilidade pode estar limitada àquele conjunto de dependências | Testar extras separadamente e documentar o escopo do suporte |
3. Se houver código nativo, trate o build como parte da compatibilidade
Pacotes com extensões em C, C++, Rust, Cython ou outras camadas compiladas precisam de mais do que uma suíte verde no checkout. O documento oficial de novidades do Python 3.15 lista mudanças e remoções na C API e também introduz uma ABI estável específica para builds free-threaded, chamada abi3t. Esse caminho exige adaptações e não é obrigatório para toda extensão.
- Construa a extensão com o Python 3.15 RC2 em cada plataforma que você pretende suportar.
- Teste o import do módulo compilado a partir da wheel instalada, não apenas a partir da árvore de fontes.
- Se o projeto declara suporte a Python free-threaded, mantenha um job específico para esse modo; se não declara, não transforme uma falha nesse modo em bloqueio do suporte convencional.
- Revise as seções de APIs removidas, APIs C alteradas e orientações de portabilidade no documento “What’s New in Python 3.15”.
4. Construa a wheel do RC e instale o artefato em um ambiente vazio
O guia oficial de packaging recomenda o pacote build para gerar source distributions e wheels, e considera obsoletas as chamadas diretas a setup.py para essa finalidade. O teste decisivo não é apenas “meus testes passam no repositório”, mas “o artefato que vou distribuir instala e funciona”.
- Crie um ambiente limpo com Python 3.15 RC2.
- Instale as ferramentas de build declaradas pelo projeto.
- Gere os artefatos com python -m build.
- Crie um segundo ambiente limpo e instale a wheel gerada em dist/.
- Execute ao menos um smoke test de importação e a parte essencial da suíte sem depender do diretório do repositório.
Esse passo encontra problemas que um install editável pode esconder, como arquivos de pacote ausentes, metadados incompletos, dados não incluídos e extensões compiladas que só falham quando carregadas da wheel.
O Python.org incentiva mantenedores a publicar wheels para Python 3.15 já durante a fase de RC, justamente para permitir que outros projetos testem suas próprias cadeias de dependências. Se a política de release do seu projeto permitir, o RC2 já é um alvo tecnicamente válido para preparar essas wheels.
5. Transforme warnings e deprecações em itens de migração
Uma suíte que passa com dezenas de avisos novos ainda pode estar carregando dívida para a próxima versão. Rode pelo menos uma execução com warnings visíveis e separe o que nasce no seu código do que vem de dependências.
- Warnings originados no seu pacote: trate como tarefa de compatibilidade e corrija antes de anunciar suporte quando indicarem uso de API em retirada.
- Warnings de dependências obrigatórias: acompanhe a correção upstream e avalie se a versão disponível impede seu suporte ao 3.15.
- Warnings de dependências opcionais: registre-os separadamente para não mascarar a compatibilidade do núcleo.
- Execução estrita: se sua suíte comportar isso, um job com python -W error::DeprecationWarning -m pytest pode transformar deprecações em falhas; faça triagem para não bloquear o projeto por avisos que pertencem apenas a terceiros.
6. Defina o critério de bloqueio antes de publicar suporte
| Situação | Bloqueia declarar suporte ao 3.15? | Leitura recomendada |
|---|---|---|
| Teste determinístico do seu pacote falha apenas no 3.15 | Sim | Corrigir ou documentar uma limitação intencional antes do release |
| A wheel não constrói ou não instala em uma plataforma que você promete suportar | Sim | O artefato de distribuição ainda não está pronto |
| Dependência obrigatória não funciona no 3.15 | Sim, para o cenário afetado | O usuário não consegue instalar ou executar a pilha suportada |
| Falha apenas em extra opcional | Depende do escopo anunciado | Separe suporte do núcleo e do extra |
| Falha em build free-threaded que o projeto não declara suportar | Não, em geral | Não confunda um modo não suportado com o interpretador convencional |
| Warning de terceiro sem impacto funcional imediato | Não automaticamente | Rastreie e reavalie; não o esconda |
Checklist final para chegar ao 1º de outubro com menos surpresa
- Python 3.15 RC2 presente na matriz de CI.
- Testes de núcleo e integrações obrigatórias passando.
- Dependências obrigatórias instalando de forma reproduzível.
- Wheel construída e instalada em ambiente limpo.
- Extensões nativas testadas nas plataformas suportadas.
- Warnings e deprecações novos triados por origem.
- Critérios de bloqueio registrados antes de anunciar suporte.
Se esses itens estiverem verdes, o RC2 oferece uma base forte para dizer que seu pacote está preparado para Python 3.15. A estabilidade da ABI torna as wheels do RC reaproveitáveis na série 3.15, mas ainda é prudente repetir a CI assim que o 3.15.0 final for publicado: a garantia de ABI não elimina correções finais de código nem mudanças no ecossistema de dependências.
