PHP 8.6 RC3: detecta las deprecaciones antes del 19 de noviembre

PHP 8.6 llega a estable el 19 de noviembre de 2026 y deprecia list(), spl_object_hash(), doubleval() y return en finally. RC3 ya se puede probar.

La RC3 se publicó el 8 de octubre de 2026 según el archivo oficial de php.net. Lo que te puede doler no es lo nuevo de esta versión, sino lo viejo: 8.6 es la última parada antes de que PHP 9 elimine de verdad funciones que hoy usas sin pensar.

El calendario real: RC4, RC5 y GA

El wiki de PHP confirma el plan de releases. Después de RC3 (8 de octubre) vienen RC4 (22 de octubre) y RC5, y el GA el 19 de noviembre. Entre hoy y esa fecha tienes tres ventanas útiles para probar:

• Ahora con RC3: ya es código congelado; lo que encuentres en RC3 es casi lo mismo que vas a tener en GA.
• Después de RC4 (22 de octubre): los RCs tardíos solo corrigen errores de build y bugs reportados; si tu proyecto pasa RC4, pasa el GA.
• Antes del 19 de noviembre: si tu CI todavía no tiene un job con 8.6, esa semana es tarde para descubrir errores.

Un RC no es estable en el sentido estricto, pero sí es suficientemente real para correr tus suites de tests. No tiene sentido esperar al GA para empezar a detectar deprecaciones: esas ya están activas desde RC1.

Cómo detectar las deprecaciones en un proyecto real

La lista completa de cambios está en la RFC de deprecaciones de PHP 8.6, aceptada e implementada. El error clásico es solo leer la lista y asumir que "en mi proyecto no uso eso". La forma correcta es dejar que PHP te avise en tus propios tests y en tu propia ejecución.

1. Enciende los avisos de deprecación en desarrollo

En local y en CI, no en producción, sube la visibilidad de E_DEPRECATED y E_USER_DEPRECATED. Con eso, cada uso de una función deprecada se marca en el log sin romper la ejecución:

; php.ini de desarrollo y CI (no producción)
error_reporting = E_ALL
display_errors = On
log_errors = On

Si prefieres no tocar el ini, en el bootstrap de los tests puedes hacerlo desde el código:

// php 8.6
error_reporting(E_ALL);
ini_set('display_errors', '1');

Con PHPUnit o Pest, revisa la salida en modo verboso. Los avisos de deprecación no fallan el test por sí solos; hay que mirar el reporte o configurar que el CI los trate como errores.

2. Corre tu suite con PHP 8.6 en un job paralelo de CI

No cambies el job principal todavía. Agrega uno nuevo con la versión RC. Con GitHub Actions, el esquema mínimo es este:

# .github/workflows/ci.yml (fragmento)
jobs:
tests-php86:
runs-on: ubuntu-latest
container: php:8.6-rc3-cli
steps:
- uses: actions/checkout@v4
- name: Instalar dependencias
run: composer install --no-interaction --prefer-dist
- name: Tests
run: vendor/bin/phpunit --display-deprecations

PHPUnit desde la serie 11 expone --display-deprecations (y el equivalente para notices y warnings). Si tu suite no lo soporta, captura la salida y filtra con grep -i deprecat en el log del job.

3. Escanea el código con Rector y PHPCompatibility

Para proyectos medianos, correr la suite no alcanza: hay código que solo se ejecuta en ciertos ramales. Rector con el set de reglas de 8.6 te marca los usos deprecados sin ejecutar nada:

# Comprueba compatibilidad sin aplicar cambios
vendor/bin/rector process --dry-run --clear-cache

Si el proyecto es Drupal o Laravel, conviene Rector con las reglas del framework más PHPCompatibility, para no recibir sugerencias absurdas sobre APIs que el framework maneja por ti.

4. En Drupal, actualiza core y revisa el código custom

Drupal 11 ya se mueve con PHP moderno, pero el código custom y los módulos contrib son el problema real. Después de instalar PHP 8.6 en un entorno de pruebas:

• Actualiza core a la última 11.x estable.
• Corre vendor/bin/drush status y revisa que no haya avisos.
• Busca en tu código los patrones de la RFC directamente:

# Detección rápida de usos deprecados en el código propio
grep -rn "spl_object_hash\|doubleval\|list(" web/modules/custom web/themes/custom

El list() en asignaciones destructurantes ([$a, $b] = $arr) es legal y no se toca; lo que se deprecó es la construcción vieja list($a, $b) = $arr. La distinción importa: un grep sin contexto te va a dar falsos positivos.

Las deprecaciones que más duelen

Más allá del listado completo, estas son las que suelen aparecer en aplicaciones reales:

• list() como constructo: refactoriza a desestructuración de arrays ([$a, $b] = ...). Es un cambio de una línea por uso.
• return dentro de finally: es la que rompe en silencio. Un return en el bloque finally pisa el valor devuelto o la excepción que se estaba propagando. PHP 8.6 lo marca, y eliminarlo en 9 va a cambiar comportamiento en código que hoy "funciona" pero no como creías. Revisa cada try/finally con un return interno.
• spl_object_hash(): usa spl_object_id() o el objeto mismo como clave de array. En colecciones de objetos, spl_object_id() es más claro y más barato.
• doubleval(): alias de (float); reemplázalo por el cast.
• Secure session defaults: no es una función deprecada, pero cambia defaults de session.cookie_* hacia valores más seguros. Si tu app depende de cookies de sesión no-HttpOnly o con atributos laxos, puede dejar de funcionar en navegador aunque PHP no emita ni un warning. Pruébalo con las sesiones reales, no solo con tests unitarios.

La lista larga de las ~30 RFC aceptadas está en php.watch; ahí también está Partial Function Application v2, que es pura sintaxis nueva y no te va a romper nada.

Qué hacer esta semana y qué dejar para después

Si mantienes un sitio Drupal o una app PHP en producción, el plan mínimo es:

1. Esta semana: job de CI con 8.6-rc3 y --display-deprecations corriendo sobre la suite completa.
2. Antes del 22 de octubre (RC4): correr Rector en dry-run y clasificar hallazgos: cambio trivial vs. cambio que requiere diseño.
3. Entre RC4 y GA: arreglar hallazgos de riesgo alto (return en finally, defaults de sesión) y dejar los alias cosméticos para el backlog.
4. Después del 19 de noviembre: promover 8.6 a job principal de CI y, cuando tu framework lo soporte de forma estable, a staging.

Lo que no conviene es esperar al GA para hacer el primer test. El 19 de noviembre va a ser idéntico a lo que ya viste en RC4/RC5, con la diferencia de que vas a tener menos días de margen si algo se rompe.

Preguntas frecuentes

¿Puedo instalar PHP 8.6 en producción antes del 19 de noviembre?

No es recomendable. Los RC son para pruebas: pueden tener bugs de build y tu hosting o cloud probablemente no los publica. Instálalos en CI y en ambientes de desarrollo; deja producción en 8.5 o en la 8.4 que ya estés soportando, hasta el GA y un parche posterior.

¿Las deprecaciones de PHP 8.6 rompen el código en el GA?

No en el GA. Deprecated significa que PHP sigue ejecutando el código y emite un warning; la eliminación real llega con PHP 9. El riesgo es que tu error_reporting en desarrollo convierta esos warnings en ruido, o que un return en finally ya esté comportándose distinto a lo que crees.

¿Drupal funciona con PHP 8.6?

Drupal 11 soporta las versiones activas de PHP según su matriz oficial; siempre verifica en drupal.org la versión de core y su soporte exacto antes de subir de versión en un sitio productivo. Lo que suele fallar no es core, sino módulos contrib y código custom con las deprecaciones de esta RFC.

¿Vale la pena probar con RC3 o mejor espero a RC4?

Si tienes CI automatizado, prueba ya con RC3: el código está congelado y los bugs que encuentres van a existir en el GA. RC4 (22 de octubre) solo corrige lo reportado; no va a traer cambios de comportamiento que no hayas visto.

¿Partial Function Application me puede romper algo?

No. Es sintaxis nueva de PHP 8.6, no deprecación. El riesgo solo aparece si usas nombres de función dinámicos o una herramienta de análisis estático que todavía no conozca la sintaxis; actualiza PHPStan o Psalm a una versión con soporte de 8.6 antes de adoptarla.

Si tu proyecto todavía no tiene un job de CI con 8.6, el siguiente paso es concretarlo esta semana: una línea en el workflow con php:8.6-rc3-cli te ahorra descubrir los return en finally el 20 de noviembre.