PrestaShop 9.2 frente a 9.1.5: ¿qué versión encaja con tu siguiente paso?
Para una tienda operativa con PrestaShop 9.1.5, la decisión no consiste solo en saber si 9.2 tiene más funciones. Consiste en saber si evaluarlas ahora resolverá un problema de negocio y qué dependencias deben entenderse antes de un cambio posterior en producción.
El 26 de septiembre de 2026, la lista oficial de versiones marca 9.1.5 como la última versión estable y 9.2.0-rc.1 como una versión preliminar. Por tanto, el mantenimiento de producción y la evaluación de 9.2 son actividades distintas. Versiones oficiales de PrestaShop.
Esta comparación supone que ya utilizas o mantienes la rama 9.1. Es una ayuda para decidir, no un procedimiento de actualización ni una introducción general a PrestaShop 9.
Una vez que tengas clara la elección de versión, utiliza el flujo de preproducción aislado de RC1 para convertir la evaluación de la candidata en un ejercicio controlado de preproducción.
Empezar por el trabajo que realiza cada versión
Tu tienda estable procesa pagos reales, comunicaciones con clientes y preparación de pedidos. Su necesidad inmediata es funcionar de forma fiable con dependencias compatibles. Un entorno RC responde a otra pregunta: ¿puede la próxima versión admitir tus flujos y qué hay que adaptar?
No hagas que un único entorno sirva para ambos propósitos. Una prueba que envía solicitudes reales de envío o eventos de marketing ya no es meramente exploratoria. Un despliegue en producción realizado solo para inspeccionar una función nueva asume consecuencias ajenas al valor del experimento.
El anuncio de 9.1.5 incluye trabajo de mantenimiento y seguridad en la rama existente. Su descripción de 9.2 como beta refleja la fecha en que se escribió ese anuncio; el índice de versiones más reciente ya identifica RC1. Esto recuerda que hay que comparar fechas en vez de tratar todas las páginas oficiales como igualmente actuales. Anuncio de 9.1.5.
Registra la base estable real que quieres conservar: versión del núcleo, versiones de módulos, tema, integraciones activas y modificaciones locales conocidas. Comparar con una tienda sin documentar resulta difícil de interpretar porque las diferencias aparentes pueden venir de la base y no de la nueva versión.
Comparar oportunidades de flujo de trabajo, no el número de funciones
La siguiente tabla convierte la orientación de 9.2 en preguntas que una tienda puede responder. No implica que 9.1.5 carezca de todos los resultados similares; los módulos y el desarrollo a medida pueden proporcionarlos ya.
| Área | Pregunta para la tienda 9.1.5 | Pregunta para una evaluación de 9.2 |
|---|---|---|
| Checkout | ¿El flujo de compra actual satisface las necesidades de pago y entrega? | ¿La opción nativa de una sola página puede cumplir las mismas reglas? |
| Datos de negocio adicionales | ¿Quién es responsable de las tablas personalizadas y las convenciones de integración? | ¿Podrían determinados campos utilizar el nuevo mecanismo nativo de extensión? |
| Asistencia administrativa | ¿Qué consultas repetidas consumen tiempo del personal? | ¿Una tarea conversacional delimitada puede devolver resultados verificables? |
| Personalización del Back Office | ¿Qué páginas y comportamientos modifican las extensiones? | ¿Esas extensiones funcionan en las rutas migradas pertinentes? |
| Clientes de integración | ¿Qué contratos se dan por supuestos hoy? | ¿Qué cambios específicos de versión requieren pruebas de contrato? |
Estas nuevas orientaciones se presentan en la secuencia de anuncios oficiales de 9.2. Trata la tabla como un marco de evaluación, no como una garantía de compatibilidad. Anuncio de funciones de la beta 9.2.
La distinción importa al presupuestar. «La nueva versión incluye un checkout» describe disponibilidad. «Nuestra extensión de fecha de entrega y nuestro módulo de pago superan el nuevo flujo» describe evidencia. Solo la segunda puede sustentar una decisión de adopción específica de una tienda.
Separar las correcciones compartidas de las diferencias reales entre versiones
Un registro de cambios largo puede exagerar la distancia aparente entre dos versiones si cada corrección se cuenta como exclusiva de una rama. Puede haber retroportaciones. Un anuncio posterior también puede repetir mejoras ya comentadas durante una beta.
Cuando una corrección concreta motive tu decisión, verifica las pruebas de la versión o del commit correspondiente para ambas bases. No deduzcas que existe un error en 9.1.5 solo porque lo mencione un registro de cambios de 9.2. Tampoco supongas que dos correcciones con nombres similares cubren el mismo comportamiento.
Un registro práctico de comparación tiene cuatro campos: el problema observado, el caso reproducible de la tienda actual, el cambio del proyecto original que podría resolverlo y el resultado de ese caso en la candidata. Así se evita elegir una versión basándose solo en el título de una incidencia.
Por ejemplo, si una integración de envío falla después de cambiar la dirección, conserva el carrito exacto, los países, las versiones de los módulos y la secuencia de acciones. Una entrada sobre el estado de entrega en el registro de cambios es una pista para investigar. No demuestra que el fallo de tu integración se haya corregido.
Distingue también una capacidad ausente de una capacidad averiada. Si tu módulo actual admite una regla de negocio que el flujo candidato no expone, ninguna cantidad de pruebas de regresión establecerá equivalencia. Esa carencia requiere una decisión de producto o integración.
Tres tiendas pueden llegar a conclusiones distintas
Un comerciante que se prepara para una campaña de temporada
Imagina una tienda cuyo checkout actual funciona y cuyo reto inmediato es una gran campaña promocional. Lo útil es mantener el entorno estable y acotar en el tiempo una revisión separada de la candidata. La campaña no se vuelve más segura porque exista una interfaz más nueva.
Elige uno o dos escenarios críticos para la primera evaluación: el comportamiento de los cupones de la promoción y los métodos de pago más usados por los clientes. Si revelan dependencias que necesiten trabajo, regístralas para un proyecto posterior. La evaluación habrá cumplido su propósito sin alterar la campaña.
Una agencia que mantiene un Back Office personalizado
Una agencia puede tener más motivos para investigar pronto aunque los comerciantes no estén listos para adoptar la próxima versión. Detectar fallos de extensiones mientras la candidata admite comentarios deja tiempo para adaptarlos e informar de ellos.
Aquí el beneficio es la preparación. Crea un mapa de cada personalización y su dependencia de página, formulario, tabla o ruta. Prueba las rutas pertinentes de la candidata y estima el esfuerzo de adaptación. La decisión puede ser «seguir dando soporte a producción en 9.1.5 mientras se valida la extensión en 9.2 RC1». Es un plan técnico coherente.
Un comerciante dependiente de un checkout de terceros
Un comerciante que paga por personalizaciones del checkout puede querer evaluar la alternativa nativa. Empieza con un inventario de equivalencia: campos, widgets de transportistas, comportamiento del pago, recuperación tras errores y reglas de cuentas de clientes.
Si el checkout existente resuelve necesidades de negocio especializadas, la opción nativa aún puede requerir desarrollo. Si esas necesidades son modestas, un prototipo centrado podría aclarar si la alternativa es viable. Ninguno de esos resultados se deduce solo de la palabra «nativo».
Estos escenarios son ilustrativos. No relatan resultados de tiendas de clientes ni afirman que una versión tenga una ventaja comercial medida.
Anteponer las pruebas de dependencias a las suposiciones
Haz preguntas concretas a los proveedores. «¿Tu módulo admite PrestaShop 9?» es demasiado amplio para un checkout nuevo o una ruta de página experimental. Pregunta qué versiones del núcleo y de los módulos se probaron, qué tema se utilizó y si la función relevante para tu tienda estaba activada.
Una jerarquía útil de evidencias es un resultado de prueba reproducible, una declaración de soporte documentada con límites de versión y una suposición sin resolver. Mantén distintas esas categorías en la comparación. El silencio de un proveedor es una dependencia pendiente, no una prueba superada.
Aplica la misma disciplina a los módulos internos. Un paquete que se instala correctamente puede fallar al guardar un formulario, procesar una notificación asíncrona o ejecutar una tarea programada. Elige casos de aceptación a partir de operaciones reales del negocio.
No uses la presencia de una interfaz experimental para justificar una promesa de soporte a largo plazo. Las notas para desarrolladores califican expresamente partes del trabajo de 9.2. Fija la implementación utilizada para evaluar y revisa el contrato cuando se publique la versión estable. Notas para desarrolladores específicas de la versión.
Escribir la decisión antes de programar el siguiente paso
Una decisión de versión debería indicar qué ocurre ahora, qué pruebas faltan y qué haría cambiar la decisión. Por ejemplo:
Mantener producción en su base estable mantenida. Evaluar el checkout candidato en una instalación desechable. Revisar la adopción cuando haya una versión estable de 9.2 y los escenarios de pago, recogida y cupones se superen con versiones de módulos compatibles.
Esa declaración es más útil que «esperar a que esté listo», porque nombra las condiciones de preparación. También evita comprometerse con una fecha de lanzamiento inventada.
Estima el trabajo en categorías separadas: investigación de compatibilidad, cambios de código necesarios, revisión de los flujos del personal, preparación del futuro despliegue y traspaso a soporte. Una pequeña diferencia de versión del núcleo no garantiza un proyecto pequeño cuando varias integraciones cambian de comportamiento a la vez.
Si la candidata no resuelve ningún problema actual y no mantienes extensiones afectadas, una breve revisión exploratoria puede bastar por ahora. Si introduce una capacidad central para tu hoja de ruta, invierte en un prototipo más profundo. Conserva sus resultados y limitaciones para que la siguiente revisión parta de pruebas y no de recuerdos.
Un registro de decisión también necesita una condición de caducidad. Revísalo cuando aparezca la versión estable oficial, cuando una dependencia crítica publique soporte o cuando cambie el requisito de negocio. Sin ese desencadenante, una decisión temporal sensata puede convertirse en una suposición indefinida de la que nadie se responsabiliza.
Preguntas que no deberían decidir por sí solas la comparación
¿9.2 es más reciente? Sí, pero el estado de la versión y la preparación de las dependencias determinan dónde encaja. Ser más nueva no demuestra su idoneidad para producción.
¿Una instalación limpia exitosa demuestra compatibilidad? Demuestra que una instalación se completó. No demuestra que tu tema, integraciones, reglas de negocio o datos históricos se comporten correctamente.
¿Deberíamos esperar a una fecha concreta de versión estable? Utiliza el anuncio oficial de lanzamiento cuando exista. Un plan de preparación debe indicar condiciones, no depender de una fecha sin verificar.
La elección práctica hoy suele consistir en dos vías coordinadas: conservar un funcionamiento fiable en la rama estable e investigar las capacidades de 9.2 importantes para tu tienda. Una decisión posterior de producción podrá apoyarse en una versión final y pruebas específicas de la tienda.
Para conocer el contexto de la plataforma, consulta nuestra guía de actualización segura de PrestaShop 8 a 9 y aplica las comprobaciones específicas de versión anteriores a la instalación que estás evaluando.