La votación masiva sobre deprecaciones de PHP 8.6 ha finalizado: se votaron 35 RFC independientes, y la mayoría fueron aprobadas. Las funciones deprecadas siguen funcionando en la propia versión 8.6 — simplemente empiezan a emitir advertencias. Parece inofensivo, pero tiene dos consecuencias prácticas.

Primero, el volumen de logs se convierte en un problema de costes. En un proyecto Laravel en producción con el registro de notices activado, una función deprecada situada en una ruta crítica invocada miles de veces por minuto genera un flujo de logs continuo y acumulativo: espacio en disco, ingesta en sistemas como Loki o ELK y, en última instancia, dinero. El síntoma aparece como «los costes de logging han subido», lo que a menudo hace que lo gestione el equipo equivocado, semanas después de que el código causante llegara a producción.

Segundo, algunas deprecaciones escapan a tu control. El código propio se corrige rápido — herramientas como Rector automatizan gran parte del trabajo —, pero los paquetes de terceros sin una versión compatible con 8.6 seguirán generando ruido hasta que el mantenedor publique una corrección, en un plazo que no depende de ti. En un stack con muchas dependencias, eso puede significar semanas de ruido irreducible en los logs.

No hay urgencia: PHP 8.5 seguirá con soporte durante años, y las deprecaciones solo se vuelven problemáticas cuando acaban convirtiéndose en eliminaciones, a menudo años después. Pero cuando llegue la actualización, el autor recomienda tratar las deprecaciones como un asunto de CI y no como un problema de logging en producción: subir primero la versión de PHP en CI, hacer que E_DEPRECATED y E_USER_DEPRECATED hagan fallar el build mediante un manejador de errores que lance una ErrorException, corregir el código propio, actualizar o vigilar los paquetes de terceros — y solo entonces desplegar el cambio de versión en producción.

Para las deprecaciones de terceros más resistentes, el artículo sugiere comprobar si ya existe una versión más reciente del paquete compatible con 8.6, si la llamada deprecada es realmente alcanzable en tu uso o es código muerto eliminable, y — con moderación — si conviene suprimir esa advertencia concreta con @ en el punto de llamada mientras se sigue el issue upstream, en lugar de desactivar por completo la barrera de CI. El resultado: una corrección de cinco minutos en una PR en lugar de investigar un pico en la factura de observabilidad tres semanas después.