Crise de Adoção de Versões do PHP: O Debate sobre a Modernização do Ecossistema em 2026

Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje a gente vai mergulhar numa conversa que tá dando o que falar nas últimas semanas. Se você trabalha com PHP, provavelmente sentiu o clima esquentar agora em julho de 2026, logo depois que saiu aquele relatório anual de uso de versões da Stitcher.io. O cenário é preocupante: a gente tá vivendo uma verdadeira "crise de adoção". De um lado, temos o PHP 8.5 brilhando com recursos novos, e do outro, uma montanha de projetos presos em versões que já estão, ou deveriam estar, no museu. Por que isso importa? Porque não é só sobre "ter a versão mais nova", é sobre segurança, é sobre performance e sobre o cansaço dos mantenedores de bibliotecas que a gente usa todo dia. O ecossistema chegou num ponto de inflexão e a pergunta que fica é: como a gente moderniza isso tudo sem quebrar a internet? Vamos discutir isso agora. Apresentadora: E para destrinchar essa treta técnica e estratégica, eu recebo hoje o Rafael Albuquerque. O Rafa é arquiteto de software, contribuidor de longa data de vários pacotes do ecossistema Laravel e PHP e um cara que tá sentindo na pele o peso de manter código compatível com versões antigas. Rafa, seja muito bem-vindo ao Allur, massa demais ter você aqui! Convidado: Valeu, Juliana! O prazer é todo meu. Olha, confesso que eu tava ansioso por esse papo, viu? O relatório da Stitcher desse ano foi tipo um balde de água gelada na nossa cara. A gente vive numa bolha de "PHP moderno", mas a realidade lá fora, nos servidores de produção, tá bem mais cinzenta. Apresentadora: Pois é, Rafael! Vamos começar por aí. Os dados mostram que a adoção do PHP 8.5 tá muito abaixo do que a gente esperava para essa altura do campeonato. Por que você acha que a galera tá "travada"? É medo de quebrar o legado ou é aquela velha história de "time que tá ganhando não se mexe"? Convidado: Cara, é um mix de tudo, sabe? Tem muito aquela cultura do "tá funcionando, não toca", principalmente em grandes empresas. Mas em 2026, isso virou um risco absurdo. O problema é que o PHP evoluiu muito rápido de uns anos pra cá, o que é ótimo! Só que as infraestruturas não acompanharam. Aí você tem o desenvolvedor querendo usar um *readonly* de última geração ou as novas APIs de concorrência do 8.5, mas o servidor da empresa ainda tá rodando PHP 8.0 ou, pasme, 7.4 via suporte estendido pago. Isso cria um abismo, né? A gente tem uma linguagem de Fórmula 1 sendo usada em estrada de terra. Apresentadora: E o perigo disso vai muito além de não poder usar a sintaxe nova, né? No post que a gente baseou esse episódio, fala muito sobre segurança e performance. Qual o tamanho do prejuízo real de ficar no "PHP de ontem"? Convidado: Olha, o prejuízo é gigante e ele é silencioso. No lado da segurança, é assustador. Versões EOL (End-Of-Life) param de receber patches. Se amanhã descobrem uma vulnerabilidade crítica, quem tá no 8.5 recebe o fix em horas, quem tá no legado fica exposto. E tem a performance, Ju. O PHP 8.5 é muito mais eficiente em memória que o 8.2 ou 8.3. Se uma empresa tem 50 microserviços rodando versão antiga, ela tá literalmente jogando dinheiro fora com infraestrutura que poderia ser 20%, 30% mais barata se o PHP estivesse atualizado. É o "imposto da obsolescência". Apresentadora: Massa você tocar nesse ponto. E agora tá rolando um movimento forte dos mantenedores — e eu sei que você faz parte dessa linha de frente — de "forçar" essa barra através do Composer. Explica pra gente: como seria essa estratégia de elevar os requisitos mínimos nos arquivos `composer.json`? Convidado: Então, essa é a nossa "arma secreta" (risos). A ideia é parar de ser passivo. Bibliotecas gigantes, tipo o Laravel, Symfony, Doctrine, e até pacotes menores de utilitários, estão começando a combinar uma ação coordenada. Se a gente mudar o `require` no `composer.json` para exigir no mínimo PHP 8.3 ou 8.4, o desenvolvedor que quiser a versão mais nova da biblioteca vai ser *obrigado* a atualizar o PHP. Isso gera um efeito cascata. Se o framework exige a versão X, todo mundo que depende dele tem que subir o degrau. É uma forma de "empurrar" o ecossistema para o futuro, porque se a gente esperar todo mundo decidir atualizar por vontade própria, o PHP vai acabar ficando estagnado enquanto outras linguagens passam a gente. Apresentadora: Entendi! É tipo dar um ultimato: "Quer as novidades? Então atualiza o motor". Mas ó, vamos ser sinceros: isso não vai gerar uma resistência pesada? Imagina o cara que tem um sistema legado imenso e vê que não pode instalar uma dependência crítica porque o PHP dele tá "velho". Qual o desafio pra esse desenvolvedor? Convidado: Nossa, o desafio é real e não é pequeno, tipo assim, a gente não tá ignorando isso. Tem a questão das dependências em cascata que você mencionou. Às vezes você quer atualizar uma coisa e descobre que tem que atualizar outras dez. O custo de migração, em tempo e teste, é alto. Mas a pergunta que as empresas precisam se fazer em 2026 é: "Qual o custo de *não* migrar?". É mais caro pagar um desenvolvedor por duas semanas de refatoração agora ou perder os dados da empresa num ataque porque o PHP 8.1 não tinha mais patch de segurança? A modernização dói, mas a estagnação mata o projeto a longo prazo. Apresentadora: Total! E do lado de quem mantém o código, deve ser um alívio imenso não ter que ficar fazendo gambiarra pra suportar versão de 5 anos atrás, né? Convidado: Massa você falar disso, Ju! É exatamente esse o ponto. Hoje, como mantenedor, eu perco horas do meu tempo livre — que eu poderia tá inovando — só garantindo que um comando novo não quebre num PHP antigo. Quando a gente limpa o suporte ao legado, o código fica mais limpo, os testes rodam mais rápido e a gente consegue focar no que realmente importa: criar ferramentas melhores pro ecossistema. É libertador! Apresentadora: Rafa, o papo tá incrível, mas a gente tá chegando no final. Para fechar: qual o seu conselho de ouro para o desenvolvedor que está ouvindo a gente agora e percebeu que o projeto dele está fazendo parte dessa estatística negativa do relatório de 2026? Convidado: O conselho é: não espera a crise chegar. Começa hoje. Faz um inventário das suas dependências, olha o que já está em EOL. Usa ferramentas como o *Rector* para automatizar a atualização do código — ele ajuda demais a pular de uma versão pra outra sem sofrer tanto. E, principalmente, conversa com o seu gestor sobre os riscos de segurança. Modernização não é "frescura de dev", é estratégia de negócio. O PHP tá voando, mas a gente precisa estar dentro do avião pra aproveitar a viagem! Apresentadora: Sensacional, Rafael! "Estratégia de negócio", falou tudo. Gente, a crise de adoção é um chamado pra gente se mexer. Se a gente quer um PHP vibrante, seguro e competitivo, a gente precisa fazer nossa parte, seja atualizando um servidor ou convencendo a diretoria de que o "legado" pode custar caro. Rafael, valeu demais pela participação, cara! Foi um prazer conversar contigo. Convidado: Valeu, Juliana! Valeu, pessoal! Vamos pra cima, PHP moderno neles! Apresentadora: E para você que ouviu a gente até aqui, as notas do episódio com os links para o relatório da Stitcher.io e as ferramentas que o Rafa citou estão lá no nosso site. Valeu por sintonizar o Allur e até o próximo episódio! Tchau!