O PHP 8.6 Beta 2 foi publicado em 27 de agosto. A palavra “beta” continua sendo o aviso principal: é uma versão para testes, não para produção. Ao mesmo tempo, o calendário já entrou numa fase em que projetos e bibliotecas ganham mais descobrindo incompatibilidades agora do que esperando a versão final em novembro.
A pergunta certa não é se chegou a hora de fazer upgrade. Ainda não chegou. É se já vale abrir uma trilha de compatibilidade no CI, sem bloquear merges, para descobrir quais pressupostos da aplicação o PHP 8.6 está mudando.
O calendário deixa espaço para encontrar problemas
O cronograma oficial prevê o Beta 3 em 10 de setembro, congelamento rígido de recursos em 22 de setembro, primeiro release candidate em 24 de setembro e lançamento geral em 19 de novembro. Datas de pré-release podem mudar, mas essa sequência mostra que o trabalho de compatibilidade já pode começar enquanto ainda há tempo para relatar regressões.
Comece com um job separado e permitido a falhar. Ele deve instalar as mesmas extensões usadas pela aplicação, resolver dependências sem mascarar conflitos e executar testes, análise estática e alguns fluxos de integração. Um exemplo conceitual no GitHub Actions:
jobs:
php-next:
continue-on-error: true
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: '8.6'
coverage: none
- run: composer update --prefer-dist --no-interaction
- run: composer testPara uma versão ainda não final, fixar uma imagem ou build conhecido torna o diagnóstico mais reproduzível. Atualize conscientemente quando sair outro beta ou RC e registre se a falha vem do PHP, de uma extensão ou de uma dependência.
Sessões merecem um teste específico
As notas de atualização atuais indicam novos padrões mais seguros: session.use_strict_mode e session.cookie_httponly passam a vir habilitados, enquanto session.cookie_samesite passa a usar Lax. São escolhas melhores para novas aplicações, mas uma mudança de padrão pode expor dependências escondidas.
Quem usa handler de sessão personalizado deve validar a criação e a aceitação de IDs. Fluxos que dependem de cookie em navegação entre sites — autenticação federada, pagamentos, iframes ou POSTs vindos de outro domínio — precisam ser exercitados com os mesmos atributos de cookie da produção. Não compensa “corrigir” tudo voltando aos padrões antigos sem entender qual fluxo quebrou.
Tipos e erros ficam menos tolerantes
O arquivo UPGRADING reúne vários casos em que funções passam a lançar ValueError ou TypeError para entradas inválidas. Também há mudanças de comportamento em SplFileObject e no conjunto de caracteres removidos por trim(), que passa a incluir form feed.
Esse tipo de ajuste raramente aparece numa demo de recurso novo, mas costuma ser onde aplicações antigas sentem uma atualização. Rode a suíte com exibição de depreciações, procure tratamentos genéricos de exceção e inclua entradas vazias, limites e formatos inválidos nos testes.
Os recursos novos também ajudam a testar o terreno
Entre as novidades listadas estão propriedades readonly com valor padrão, aplicação parcial de funções, a nova API Time\Duration, erros JSON com localização e uma API de polling. OpenSSL, streams, sockets, PDO PostgreSQL e URI também recebem capacidades novas.
Não é preciso adotar nada disso para testar compatibilidade. Aliás, separar os dois trabalhos ajuda: primeiro prove que a aplicação atual roda; depois experimente recursos novos em branches pequenos. Assim, uma falha não fica misturada com uma refatoração oportunista.
O checklist que já vale executar
- adicionar PHP 8.6 como job não bloqueante no CI;
- rodar com depreciações visíveis e guardar os logs;
- testar sessões, cookies e integrações entre domínios;
- validar extensões nativas e plataforma exigida pelo Composer;
- repetir a rodada nos próximos RCs antes de tornar o job obrigatório.
Beta 2 é cedo para prometer suporte e tarde demais para fingir que novembro está longe. A vantagem de testar agora é transformar o upgrade futuro numa lista conhecida de ajustes, não numa maratona no dia do lançamento.