PHP 8.6 RC3: o teste de compatibilidade agora precisa virar plano de rollout

PHP · "Loop"

O PHP 8.6 RC3 foi disponibilizado em 8 de outubro de 2026. Continua sendo uma versão de teste e a orientação oficial é não usá-la em produção. A diferença em relação à fase beta está no tipo de trabalho que ela permite: com o congelamento de recursos já em vigor, o time pode parar de apenas coletar incompatibilidades e começar a fechar um plano de adoção.

Quando o PHP 8.6 chegou ao Beta 2, fazia sentido adicionar um job não bloqueante e descobrir o terreno. No RC3, a pergunta passa a ser quais falhas ainda impedem suporte, quais dependências precisam de atualização e como a troca será observada e revertida depois da versão final.

RC não é sinal verde para produção

Release candidate indica uma linha estabilizada para encontrar regressões antes do lançamento geral, não uma garantia de ausência de bugs. O calendário oficial ainda prevê RC4 em 22 de outubro, RC5 em 5 de novembro e GA em 19 de novembro. Essas datas podem mudar conforme os testes.

O ambiente certo para o RC3 é uma matriz de CI, um staging representativo ou uma cópia descartável de produção sem tráfego real. Ele deve receber a mesma aplicação, extensões, configuração e dependências nativas usadas no deploy. Testar apenas o interpretador com uma suíte pequena deixa de fora justamente as diferenças que mais atrasam upgrades.

Transforme a matriz de CI em uma lista de bloqueadores

Um job permitido a falhar foi útil no começo. Agora cada falha precisa de dono e classificação. Um modelo simples evita misturar problema do PHP com incompatibilidade do ecossistema:

  • Core: comportamento mudou ou existe uma possível regressão no PHP.
  • Extensão: a versão usada ainda não compila ou não declara suporte.
  • Dependência: Composer, framework ou biblioteca bloqueia a plataforma.
  • Aplicação: depreciação, tipo mais estrito ou pressuposto incorreto no código.
  • Infraestrutura: imagem, agente, observabilidade ou configuração ainda não acompanha a nova versão.

Guarde a versão exata do RC e das extensões no log. Se o mesmo teste passa no PHP atual e falha no 8.6 RC3 com entradas reproduzíveis, o relato para o projeto ou mantenedor fica muito mais útil.

Conexões persistentes merecem um cenário próprio

Uma mudança aceita para o PHP 8.6 eleva as versões mínimas relacionadas a MySQL e MariaDB para que PDO e mysqlnd possam usar COM_RESET_CONNECTION ao reutilizar conexões persistentes. A intenção é devolver a conexão a um estado limpo, em vez de carregar transação ou configuração de sessão de um uso anterior.

Aplicações em bancos muito antigos podem continuar executando, mas perdem o uso de conexões persistentes. Aplicações que, por acidente, dependiam de estado atravessando a reutilização podem revelar bugs. O risco é parecido com o contrato de workers PHP persistentes: qualquer estado reaproveitado precisa ter propriedade e limpeza explícitas.

  • confirme a versão real de MySQL ou MariaDB em cada ambiente;
  • execute transação, erro, rollback e nova requisição na mesma conexão;
  • teste timezone, charset e outras opções de sessão;
  • observe falhas de conexão e crescimento do pool;
  • não conclua pelo benchmark que a conexão continua semanticamente limpa.

Depreciações precisam de orçamento, não de silêncio

O PHP 8.6 acrescenta depreciações que apontam para remoções futuras. Em vez de ocultar E_DEPRECATED para fazer a pipeline passar, capture o volume por origem. Código da aplicação pode ser corrigido já; dependências exigem versão nova, patch ou decisão de substituição.

php -d error_reporting=E_ALL \
    -d display_errors=1 \
    vendor/bin/phpunit

Uma suíte verde com depreciações escondidas não mede a mesma coisa que uma execução limpa. Ao mesmo tempo, tornar qualquer aviso transitivo um bloqueio imediato pode impedir progresso. Registre uma linha de base, faça o número cair e defina quais mensagens precisam chegar a zero antes do rollout.

O plano para a versão final pode ser escrito agora

  1. Fixe o RC3 numa matriz que reproduza extensões e configuração de produção.
  2. Feche bloqueadores por camada e repita a rodada a cada RC.
  3. Monte uma imagem candidata sem substituir a imagem estável.
  4. Defina canário, métricas de erro, latência, memória e filas.
  5. Mantenha a imagem anterior e um caminho de rollback sem migração irreversível.
  6. Só transforme o job em obrigatório quando a versão final e as dependências suportadas estiverem disponíveis.

O RC3 não antecipa a data do upgrade; ele antecipa o conhecimento necessário para que o upgrade não vire improviso. Se a aplicação ainda não tem matriz, inventário de extensões e rollback, o melhor resultado desse release é revelar essa lacuna enquanto ainda há várias semanas até o GA planejado.

Fontes

Leia também