Actualización OJS 3.6: pruebas del flujo editorial

Actualización OJS 3.6: pruebas del flujo editorial

La actualización OJS 3.6 exige separar el anuncio de una decisión de cambio. PKP presenta 3.6 como una versión próxima: su primera entrega está programada para el otoño de 2026, no como una liberación disponible.[3] Mientras tanto, OJS 3.5 es la LTS vigente y soportada; 3.6 pertenece a la línea STS prevista.[1]

La decisión razonable no es calendarizar producción por una presentación. Es construir una prueba reproducible con una copia protegida de la revista, una muestra editorial exigente y criterios explícitos para avanzar o volver atrás.

Diagrama propio. Resume la secuencia de ensayo antes de cualquier ventana de producción.

Actualización OJS 3.6: anuncio y disponibilidad

OJS 3.6 fue anunciado por PKP, pero este anuncio no equivale a una versión liberada para instalar. El propio comunicado identifica la entrega inicial como programada para el otoño de 2026.[3] Hasta que PKP publique la versión y su material de liberación, no conviene convertir el anuncio en una fecha comprometida para producción.

La hoja de lanzamientos de PKP marca OJS 3.5 como LTS soportada. También explica que las ramas impares, como 3.5, corresponden a LTS, mientras que las pares, como 3.6, son STS.[1] Para una revista que necesita una base soportada ahora, 3.5 sigue siendo la referencia vigente. La ruta de actualización a 3.5 está explicada en la guía de migración de OJS ONE.

La novedad anunciada para 3.6 es relevante para producción editorial: un editor HTML integrado y generación de HTML, PDF y JATS XML desde HTML como fuente canónica.[2] PKP también declara que el flujo tradicional con herramientas de escritorio o servicios externos seguirá disponible.[2] Por eso una prueba debe comparar el camino integrado con el proceso que la revista ya puede operar, sin asumir que el segundo desaparece.

Levanta un inventario que permita decidir

El inventario no es una lista administrativa. Es la base para reproducir la plataforma, reconocer dependencias y definir qué validará cada rol. Hazlo antes de crear staging y deja una persona responsable por cada ítem.

• Registra versión exacta de OJS, PHP, base de datos, servidor web, extensiones y tareas programadas.
• Lista revistas, rutas de archivos privados y públicos, espacio usado, configuración, certificados, correo y cron.
• Identifica plugins activos, su función editorial, dependencia, mantenedor y alternativa si falla.
• Documenta el tema, CSS, plantillas modificadas, cambios al código y componentes de analítica o identidad.
• Mapea depósitos DOI, OAI-PMH, autenticación, correo, almacenamiento e integraciones que intercambian datos.
• Marca qué usuarios validarán envío, revisión, corrección, producción, publicación y lectura.
• Guarda evidencia de un respaldo recuperable de código, configuración, archivos y base de datos.

La guía de migración de OJS ONE recuerda que una recuperación requiere software, configuración, archivos privados, archivos públicos y base de datos.[4] No basta con confirmar que existe un archivo comprimido. Restaura la copia en una instancia aislada, abre una galera, descarga un archivo y comprueba que las relaciones editoriales siguen presentes. Ese ensayo es la evidencia útil para una reversión.

Prepara staging, plugins y tema sin exponer la revista

Staging debe ser una copia separada, con acceso restringido, indexación bloqueada, correo saliente controlado y conectores externos en modo seguro. Su objetivo es observar el cambio sin notificaciones involuntarias, depósitos reales ni alteración de datos externos.

Crea una matriz simple para plugins y tema. En la primera columna, escribe componente y versión. Luego registra función, evidencia de compatibilidad cuando sea publicada, resultado del ensayo, responsable y decisión: mantener, reemplazar, desactivar o escalar. Aplica el mismo criterio a un tema hijo, CSS propio y plantillas. Un portal puede abrir su portada y aun así ocultar un fallo en un formulario, una tarea automática o una galera.

En esta etapa no reemplaces procesos estables por anticipación. PKP señala que el editor integrado será una alternativa dentro del software y que el flujo heredado permanece disponible.[2] Conserva el proceso vigente durante el ensayo y define la condición que permitiría ensayar la alternativa nueva después de una liberación efectiva.

Usa una muestra que presione el flujo editorial

Una prueba breve con texto plano aporta poca señal. Selecciona una muestra controlada que represente los casos difíciles de la revista: artículo con resumen bilingüe, autores con identificadores, referencias extensas, tabla con celdas combinadas, ecuación, figura con pie, enlace interno y corrección en etapa editorial. Usa copias autorizadas o material ficticio; no expongas manuscritos ni datos personales.

PKP anticipa que, durante la transformación, se preservan los diseños de tablas y fórmulas, pero advierte que estilos complejos o atípicos pueden no transformarse de manera perfecta.[3] La muestra debe comprobar ese límite de forma visible. No la reduzcas a una sola galera PDF.

Para cada caso, define resultado esperado y evidencia:

1. Envía o carga el archivo de prueba y confirma que el cuerpo se convierte en HTML editable si la función está disponible.
2. Revisa encabezados, listas, tablas, ecuaciones, figuras, texto alternativo, enlaces y referencias.
3. Genera HTML, PDF y JATS XML cuando la función exista, y compáralos con el material de entrada y el resultado de publicación.
4. Corrige una referencia, una celda y una fórmula; vuelve a generar los archivos y verifica qué se actualiza.
5. Recorre asignación editorial, revisión, corrección, producción y publicación con cuentas de prueba.
6. Comprueba la vista pública, descarga de galeras, metadatos, OAI-PMH, correo y tareas que afecten a esa revista.
7. Registra capturas, mensajes de error, archivos generados y una decisión por cada defecto detectado.

El anuncio de PKP explica que solo el cuerpo del artículo se comparte con el editor integrado y que los metadatos aparecen en una barra lateral.[2] Por eso valida por separado título, autores, resumen, identificadores y referencias, en vez de concluir que la conversión del cuerpo prueba el registro completo.

Capacita por tarea, no por pantalla

La capacitación debe ocurrir sobre staging y con la misma muestra usada en la aceptación. Asigna ejercicios por rol: quien recibe manuscritos debe cargar y detectar problemas iniciales; quien corrige debe editar cuerpo y referencias; producción debe revisar la salida de cada formato; quien administra debe observar errores, tareas, permisos y restauración.

Pide que cada participante complete una operación y deje evidencia: una galera revisada, un dato corregido, una incidencia documentada o una recuperación ensayada. Este enfoque revela dudas de operación antes de una ventana de cambio y evita que el equipo aprenda con envíos reales.

Incluye una guía breve de decisión. Debe indicar cuándo usar el camino habitual, cuándo ensayar la función integrada y a quién escalar si una tabla, fórmula o estilo pierde fidelidad. La meta no es forzar un único procedimiento: es sostener control editorial mientras cambia la herramienta.

Define aceptación y reversión antes de intervenir

No programes producción hasta acordar qué resultado permite seguir y qué señal obliga a detenerse. La lista de aceptación debe incluir acceso por rol, archivos de prueba, estado de envíos y revisiones, visualización pública, correo, tareas programadas, plugins usados, tema, integraciones y metadatos. Cada prueba necesita responsable, evidencia y criterio de aprobación.

La reversión exige un punto de corte. Define cuándo se congelan cambios editoriales, quién autoriza abrir o cerrar la ventana, qué copia coherente se restaurará y cómo se registrarán acciones ocurridas durante el ensayo final. Si una actualización altera la base de datos, volver solo el código anterior no recupera una plataforma consistente. La guía de OJS ONE recomienda recuperar un conjunto coherente de código, configuración, archivos y datos.[4]

Cierra el plan con una decisión explícita: continuar, repetir el ensayo, mantener 3.5 LTS o recuperar la copia. Esperar una liberación efectiva de 3.6 no es inacción; permite hacer la prueba sobre el software que realmente se instalaría.

Errores que conviene evitar

El primer error es decir que OJS 3.6 ya está liberado. La fuente de PKP habla de una primera entrega programada, por lo que la comunicación interna debe usar “anunciado” o “previsto”.[3]

El segundo error es probar con una revista vacía. Las transformaciones se evalúan con tablas, fórmulas, referencias y estilo representativo, especialmente porque PKP identifica límites posibles en estilos complejos.[3]

El tercero es llamar respaldo a una copia no restaurada. La recuperación se valida restaurando en una instancia separada y comprobando datos y archivos, no solo revisando que el respaldo terminó.

El cuarto error es capacitar después del cambio. Staging permite practicar, recoger incidencias y ajustar instrucciones sin afectar publicaciones ni comunicaciones reales.

Preguntas frecuentes

¿OJS 3.6 ya está disponible para producción?

No. Al 23 de octubre de 2026, la comunicación de PKP sitúa la primera entrega de 3.6 en el otoño de 2026.[3] Revisa la página de lanzamientos y el material de liberación antes de escoger una versión para instalar.

¿Por qué mantener OJS 3.5 mientras se evalúa 3.6?

Porque 3.5 aparece como LTS soportada en la página de lanzamientos de PKP.[1] La evaluación de 3.6 puede avanzar en planificación y diseño de pruebas, sin reemplazar una base vigente por una versión anunciada.

¿Qué debe contener la muestra de pruebas?

Incluye tablas, fórmulas, referencias, figuras, enlaces, correcciones y la publicación de HTML, PDF y JATS XML cuando esa función esté disponible. Así podrás contrastar el resultado con el material que la revista procesa y detectar límites de estilo.[3]

Evalúa la actualización con acompañamiento técnico

Si necesitas ordenar inventario, staging, respaldo, pruebas y reversión antes de una actualización, revisa el servicio de operación OJS. El alcance se define según la instalación, su flujo editorial y la evidencia reunida en el ensayo.

Fuentes

1. PKP, PKP Software Releases — consultado 2026-10-23.
2. PKP, OJS 3.6: Bringing Manuscript Editing and Production under one Roof — consultado 2026-10-23.
3. PKP, Upload, Transform, Publish: Inside OJS 3.6’s File Production and Toolset — consultado 2026-10-23.
4. OJS ONE, Actualizar OJS a 3.5 LTS: requisitos y ruta de migración — consultado 2026-10-23.