Redmine 7: webhooks, Rails 8 y 20 años de proyecto — novedades y cómo actualizar

El 30 de junio de 2026 el proyecto Redmine publicó la versión 7.0.0, y lo hizo justo cuando se cumplían 20 años desde la primera release de 2006. Para una herramienta de gestión de proyectos que muchas empresas instalaron hace una década y desde entonces solo han tocado para aplicar parches, esa cifra no es una anécdota de marketing: es exactamente la razón por la que sigue en producción. Redmine no ha desaparecido ni se ha convertido en un SaaS con precio por usuario, y eso, para un departamento de IT que ya tiene suficientes migraciones pendientes, vale mucho.

Redmine 7.0.0 cierra 122 incidencias e incorpora el cambio funcional que la comunidad llevaba años pidiendo: webhooks nativos sobre eventos. Por debajo, el salto es aún mayor, porque la aplicación se ha migrado a Rails 8 y ya admite Ruby 4.0. Se suma un rediseño de la cabecera, soporte real para idiomas de escritura derecha-izquierda, previsualización de más formatos de fichero y una limpieza de dependencias JavaScript que llevaba tiempo haciendo falta.

Dos meses después, el 26 de agosto de 2026, llegó Redmine 7.0.1 junto con 6.1.4 y 6.0.11: una release de seguridad que corrige cinco fallos, entre ellos un XSS almacenado en el formateador Textile y varios bypass de visibilidad. Si estás evaluando el salto, ese es el punto de partida real: no instales 7.0.0, instala 7.0.1.

En este artículo repasamos qué cambia de verdad en Redmine 7, qué versiones siguen recibiendo soporte tras el fin de vida de la rama 5.1, a quién le compensa actualizar ya y quién puede esperar, y cómo dar el salto sin dejar a tu equipo sin gestor de tareas un lunes por la mañana. Lo escribimos desde la posición de quien mantiene estas instalaciones en servidores de clientes, no desde la nota de prensa.

1. Redmine 7 en contexto: qué significan 20 años de proyecto

Conviene poner la release en perspectiva antes de entrar en el detalle técnico. Redmine nació en 2006 como una alternativa libre a las herramientas propietarias de seguimiento de incidencias. Dos décadas después sigue siendo una aplicación Ruby on Rails que se instala en tu servidor, guarda los datos en tu base de datos y no te cobra por asiento. En un mercado donde el coste por usuario de las suites comerciales se ha convertido en una partida presupuestaria sensible, esa propiedad es precisamente la ventaja competitiva.

1.1 Las cifras de la release

La 7.0.0 no es una release cosmética. Cierra 122 incidencias y toca las tres capas de la aplicación: el framework, la interfaz y el modelo de integración con sistemas externos. Es, en la práctica, la mayor actualización desde la 6.0. Para un administrador eso se traduce en dos cosas: hay ganancias reales que justifican el trabajo, y hay superficie de cambio suficiente como para no actualizar en caliente un viernes por la tarde.

1.2 Por qué una versión mayor importa en una decisión de stack

Cuando una dirección técnica evalúa si mantener Redmine o migrar a una herramienta comercial, el argumento en contra suele ser el mismo: «es software antiguo, se quedará atrás». La 7.0 es la respuesta a ese argumento. Un proyecto que en 2026 migra a Rails 8, adopta Ruby 4, reescribe su capa de gráficos para usar SVG nativo y añade webhooks no es un proyecto en mantenimiento pasivo. Es un argumento que conviene tener a mano en la conversación con negocio, igual que lo es entender la deuda técnica acumulada y cómo medirla antes de decidir si se reemplaza o se moderniza una herramienta.

2. Webhooks nativos: el cambio funcional más importante

Hasta la 7.0, integrar Redmine con el resto del ecosistema de la empresa significaba una de dos cosas: instalar un plugin de terceros de mantenimiento incierto, o montar un proceso que hiciera polling contra la API REST cada pocos minutos. Lo primero añadía una dependencia que rompía en cada actualización; lo segundo generaba carga inútil y latencia de minutos entre que algo pasaba en Redmine y el sistema de destino se enteraba.

Redmine 7 incorpora webhooks sobre eventos directamente en el núcleo. Cuando ocurre algo relevante —se crea una tarea, se actualiza, se añade una nota—, Redmine lanza una petición HTTP POST con el payload en JSON hacia el endpoint que hayas configurado. El receptor reacciona en el momento.

2.1 Cómo se activan

Los webhooks vienen desactivados por defecto. Es una decisión de diseño correcta: una instalación que se actualiza no empieza de golpe a emitir tráfico saliente hacia ninguna parte. Un administrador tiene que habilitarlos explícitamente y definir los endpoints. Para un responsable de seguridad esto es importante, porque significa que la superficie nueva de la aplicación no se abre sin intervención humana.

Conviene tratar cada endpoint configurado como lo que es: un canal por el que salen datos de tus proyectos hacia otro sistema. Endpoint sobre HTTPS, validación del origen en el receptor, y ningún dato sensible en la URL.

2.2 Casos de uso que ahora dejan de necesitar plugin

• Automatización con n8n. Un webhook de Redmine a un flujo de n8n permite encadenar acciones sin escribir un servicio intermedio: abrir una tarea en Redmine y que se cree la ficha en el CRM, se avise al canal del equipo y se registre en el cuadro de mando. Si vas a montar el receptor en tu propia infraestructura, nuestra guía para instalar n8n en producción con Docker y PostgreSQL cubre el lado del receptor.
• CI/CD. Disparar un pipeline cuando una tarea pasa a un estado concreto, o al revés, cerrar la tarea cuando el despliegue termina en verde.
• Notificaciones a chat. Mensajes en el canal del proyecto sin que cada usuario tenga que sufrir el correo de Redmine.
• Sincronización con CRM o ERP. El patrón de integración por eventos, que ya funciona bien entre otros sistemas de negocio, por fin es aplicable a Redmine sin capas intermedias.

2.3 Lo que los webhooks no resuelven

Un webhook es una entrega «al menos una vez» y sin garantías fuertes: si tu receptor está caído, el evento se pierde. Si la información que viaja por ahí es crítica para un proceso de negocio, el receptor debe ser idempotente y conviene mantener una reconciliación periódica contra la API REST como red de seguridad. No es un bus de mensajes, y tratarlo como si lo fuera es la forma habitual de acabar con datos divergentes entre dos sistemas.

3. Rails 8 y Ruby 4: qué implica en tu servidor

Este es el cambio que más trabajo da y del que menos se habla. Redmine 7.0 corre sobre Rails 8.1, mientras que las ramas 6.0 y 6.1 se quedan en Rails 7.2 y la 5.1 sigue anclada en Rails 6.1. No es un detalle: un salto de versión mayor del framework es lo que rompe plugins, temas y cualquier parche local que alguien aplicara hace años y no documentara.

3.1 Matriz de compatibilidad

Versión	Ruby	Rails	Estado
Redmine 7.0	3.2, 3.3, 3.4, 4.0	8.1	Estable (actual)
Redmine 6.1	3.2, 3.3, 3.4	7.2	Estable
Redmine 6.0	3.1, 3.2, 3.3	7.2	Legacy
Redmine 5.1	—	6.1	Fin de soporte

En cuanto a bases de datos, tanto la 7.0 como la 6.1 piden PostgreSQL 14 o superior, MySQL 8.0 a 8.4, SQL Server posterior a 2012 o SQLite 3. Si tu instalación arrastra un MySQL 5.7 —cosa más común de lo que parece en servidores que nadie ha tocado en años—, esa migración de base de datos es un proyecto en sí mismo y hay que planificarlo antes, no durante.

3.2 La regresión de Ruby 4.0.0–4.0.3

Aquí hay una trampa concreta que conviene anotar. Redmine 7 admite Ruby 4.0, pero las versiones 4.0.0 a 4.0.3 sufren una ralentización severa al renderizar el wiki por una regresión del propio runtime de Ruby. Se corrigió en 4.0.4.

La recomendación práctica es directa: si vas a Ruby 4, usa 4.0.4 o posterior. Si tu distribución todavía no empaqueta esa versión, quédate en Ruby 3.4, que está plenamente soportado por la 7.0 y te evita el problema por completo. Es el tipo de detalle que separa una actualización tranquila de una mañana entera respondiendo tickets de usuarios que dicen que «el wiki va lentísimo».

3.3 El servidor de aplicaciones y el proxy

Un cambio de versión mayor de Rails es también un buen momento para revisar la capa de delante. Si sirves Redmine detrás de un proxy inverso, merece la pena aprovechar la ventana de mantenimiento para repasar cabeceras, compresión y tiempos de espera; nuestra guía de optimización de Nginx en servidor dedicado cubre los ajustes que más se notan en aplicaciones Rails con adjuntos pesados.

4. Interfaz: rediseño de cabecera, RTL y previsualización

4.1 Cabecera más ligera y menú de usuario

La barra de navegación superior se ha rediseñado con menos peso visual y un menú de usuario propio. Es un cambio pequeño en código y grande en percepción: la primera pantalla que ve el equipo al entrar deja de parecer una aplicación de 2012. Si en tu organización hay resistencia a Redmine por motivos estéticos —y la hay más a menudo de lo que se admite—, esta es la release que conviene enseñar.

4.2 Soporte RTL de verdad

El soporte para idiomas de escritura derecha-izquierda se ha rehecho sustituyendo propiedades CSS físicas por propiedades lógicas, integrando las sobrescrituras en la hoja principal y adaptando también los diagramas de Gantt. Para una empresa con operaciones en Oriente Medio o con equipos que trabajan en árabe o hebreo, esto pasa de ser un parche a ser funcionalidad soportada.

4.3 Previsualización de archivos y pegado de hojas de cálculo

Redmine 7 previsualiza documentos de Microsoft Office, LibreOffice Writer, PDF, AVIF y SVG directamente en el navegador. En la práctica significa que dejas de descargar el adjunto para ver si es la versión buena del documento.

El segundo detalle es pequeño y se agradece a diario: se puede pegar contenido desde una hoja de cálculo y que se convierta en una tabla CommonMark o Textile. Quien haya intentado alguna vez trasladar a mano una tabla de Excel a una descripción de tarea entenderá el ahorro. Es el mismo tipo de fricción que aparece cuando se trabaja la documentación funcional de proyectos IT: el contenido existe, el problema es el trasvase.

5. Rendimiento y limpieza de dependencias

5.1 Dónde se nota la mejora

Las optimizaciones de esta release van a las operaciones que más se repiten durante el día: la búsqueda de usuarios al escribir una mención con arroba, la caché del autocompletado y las transiciones de flujo de trabajo, que ahora se resuelven con búsquedas por hash en lugar de recorrer la tabla. En instalaciones con cientos de usuarios y decenas de roles, la diferencia se percibe al escribir en un campo de texto, que es exactamente donde la lentitud resulta más irritante.

5.2 Menos JavaScript heredado

Se ha eliminado Raphael.js en favor de las APIs SVG nativas del navegador, se ha sustituido la gema html-pipeline por Loofah y ChartJs se ha actualizado a módulos ES. Traducido: menos código de terceros que mantener, menos superficie de vulnerabilidad en dependencias y páginas que cargan menos kilobytes. Es el tipo de trabajo que no aparece en ninguna captura de pantalla pero que determina si dentro de tres años la actualización siguiente será factible o dolorosa.

6. Seguridad: el parche 7.0.1 no es opcional

El 26 de agosto de 2026 el proyecto publicó Redmine 7.0.1, 6.1.4 y 6.0.11 para corregir cinco problemas de seguridad. Son estos:

• Peticiones de API que afectan a la sesión del usuario y permiten eludir políticas de seguridad (defect #44249).
• XSS almacenado en el formateador Textile mediante la restauración de etiquetas notextile, bautizado por el reportante como «Frankenstein tag» (defect #44308).
• Los endpoints anidados de relaciones entre tareas no respetaban la visibilidad de la tarea de origen (defect #44309).
• Las actualizaciones de inherit_members en proyectos hijo eludían la autorización de gestión de miembros (defect #44310).
• Filtrado del parámetro key en los registros, para que las claves de API dejen de acabar escritas en los logs (patch #44371).

Vale la pena detenerse en el patrón: tres de los cinco son problemas de control de acceso, no de inyección. Los bypass de visibilidad y de autorización son exactamente el tipo de fallo que un escáner automático no detecta y que, en una instalación donde proyectos de clientes distintos conviven en la misma base de datos, tiene consecuencias contractuales. Es la categoría que OWASP sitúa desde hace años en lo alto de su Top 10 por buenas razones.

La 7.0.1 incluye además Rails 8.1.3.1, corrige una regresión de rendimiento en el formateo de texto que afectaba a contenedores con muchos adjuntos, arregla el borrado de usuarios cuando hay aplicaciones OAuth2 autorizadas y restaura el acceso por contraseña para administradores con doble factor obligatorio.

6.1 Sudo mode y endurecimiento del servidor

La 7.0 activa además el sudo mode por defecto: las acciones administrativas sensibles piden reconfirmar la contraseña. Es una molestia de dos segundos que corta en seco el escenario de la sesión abierta en un portátil sin bloquear.

Ninguna de estas medidas sustituye al trabajo de base en el servidor. Si tu Redmine es accesible desde internet, el firewall, el acceso SSH, los backups verificados y la monitorización siguen siendo la primera capa; lo hemos desarrollado en nuestra guía de ciberseguridad en servidores con poco presupuesto.

7. Ciclo de vida: 5.1 en fin de soporte, 6.0 legacy, 6.1 y 7.0 estables

Con la llegada de la 7.0 el proyecto reordenó las ramas soportadas, y este es probablemente el dato más accionable de todo el artículo:

7.1 Si estás en 5.1: tienes un problema con fecha

La rama 5.1 llegó a su fin de vida con la 5.1.13, publicada el 15 de junio de 2026. No habrá más parches. Cualquier vulnerabilidad que aparezca a partir de ahora en esa base de código —incluidas las cinco de agosto, que no se han corregido en 5.1— se queda sin arreglar oficialmente.

Si tu instalación está ahí, el salto no es opcional, es una cuestión de calendario. Y ojo con el tamaño real del salto: de 5.1 a 7.0 hay dos versiones mayores del framework de por medio (Rails 6.1 a 8.1). Normalmente compensa hacerlo en dos etapas, pasando por 6.1, en lugar de intentar un salto único.

7.2 Si estás en 6.0 o 6.1: puedes planificar con calma

La 6.0 es ahora la rama legacy estable y la 6.1 es estable de pleno derecho; ambas recibieron parches el 26 de agosto. Tienes margen para planificar el salto a 7.0 en la ventana de mantenimiento que te convenga, en lugar de hacerlo con prisa.

Lo que no conviene es dejar pasar dos años y repetir la situación de quien hoy está en 5.1. Es el mismo patrón que se ve en otras aplicaciones de negocio autoalojadas, desde ERPs hasta CRMs: mantenerse una versión por detrás es gestionable, mantenerse tres es un proyecto de migración. Lo comentamos al analizar el soporte extendido y el roadmap de SuiteCRM 8.9, y la lógica es idéntica.

8. Cómo actualizar a Redmine 7 sin romper producción

Este es el procedimiento que seguimos en instalaciones de cliente. No es complicado; es simplemente largo, y los problemas aparecen cuando se salta alguno de los pasos previos.

8.1 Antes: inventario honesto

• Plugins instalados. Lista completa, con versión y estado de mantenimiento de cada uno. Para cada plugin, comprobar si existe una versión compatible con Redmine 7 y Rails 8.1. Este punto es el que decide si la actualización dura una tarde o tres semanas.
• Temas personalizados. El rediseño de cabecera y el cambio a propiedades lógicas de CSS pueden descolocar un tema propio.
• Parches locales. Cualquier fichero del núcleo modificado a mano. Si nadie lo documentó en su día, un diff contra la versión limpia lo saca a la luz.
• Versión de Ruby y de base de datos actuales, contrastadas con la matriz de la sección 3.
• Integraciones existentes contra la API REST, que pueden ser candidatas a reescribirse como webhooks después.

Si el inventario revela más incógnitas que certezas, es señal de que toca una auditoría técnica previa antes de tocar nada.

8.2 Backup y entorno de pruebas

Copia de la base de datos, copia del directorio files/ con los adjuntos, copia de config/. Y después, lo que de verdad importa: restaurar esa copia en un servidor de pruebas y comprobar que arranca. Un backup que nunca se ha restaurado no es un backup, es una carpeta.

Sobre ese entorno de pruebas se ejecuta la actualización completa. Es la única forma de descubrir qué plugin rompe sin descubrirlo en producción.

8.3 El procedimiento

1. Poner la aplicación en mantenimiento y parar el servidor de aplicaciones.
2. Actualizar Ruby si hace falta, respetando la regla de la sección 3.2: Ruby 3.4, o 4.0.4 en adelante.
3. Actualizar la base de datos si vienes de una versión por debajo de los mínimos.
4. Desplegar el código de Redmine 7.0.1, no 7.0.0.
5. Instalar las gemas con bundle install --without development test.
6. Ejecutar las migraciones con bundle exec rake db:migrate RAILS_ENV=production.
7. Migrar las de los plugins con bundle exec rake redmine:plugins:migrate RAILS_ENV=production.
8. Limpiar la caché con bundle exec rake tmp:cache:clear.
9. Arrancar y revisar el log de producción antes de abrir el acceso a los usuarios.

8.4 Después: verificación

Revisar el renderizado del wiki (por la regresión de Ruby), los diagramas de Gantt (por el cambio de Raphael.js a SVG), los adjuntos, el envío de correo, la autenticación LDAP o SAML si la usas, y los flujos de trabajo personalizados. Si vas a habilitar webhooks, hazlo en una segunda ventana, no en la misma: una cosa es actualizar y otra es abrir un canal de salida nuevo.

9. Plugins y temas: el punto de fricción real

Merece sección propia porque es donde se atascan la mayoría de las actualizaciones. Redmine 7 corre sobre Rails 8.1, y un plugin escrito para Rails 6.1 tiene muchas papeletas de no arrancar. Las opciones, por orden de preferencia:

1. Actualizar el plugin si su autor ha publicado versión compatible.
2. Prescindir de él si la funcionalidad ya está en el núcleo. Con los webhooks nativos, varios plugins de integración dejan de tener sentido.
3. Adaptarlo tú si es pequeño y el código es legible. Suele ser cuestión de APIs de Rails renombradas.
4. Sustituirlo por una integración externa vía webhook o API REST, que es más fácil de mantener a largo plazo que un plugin acoplado al núcleo.

Lo que no funciona es quedarse en una versión antigua indefinidamente por no perder un plugin. Ese es el mecanismo exacto por el que una instalación acaba cinco años atrasada y expuesta.

10. Errores frecuentes al actualizar Redmine

• Instalar 7.0.0 en lugar de 7.0.1. Te llevas cinco vulnerabilidades conocidas el primer día.
• Saltar de Ruby a la 4.0.0 sin leer las notas y pasar la semana siguiente investigando por qué el wiki tarda segundos en cargar.
• No probar la restauración del backup. El momento de descubrir que el dump está corrupto no es a mitad de la ventana de mantenimiento.
• Olvidar redmine:plugins:migrate y encontrarse con errores de columnas inexistentes en plugins que sí eran compatibles.
• Actualizar y habilitar webhooks a la vez, de modo que cuando algo falla no sabes cuál de los dos cambios lo causó.
• No avisar al equipo del rediseño de cabecera. Un aviso de dos líneas el día antes ahorra una mañana de tickets.

11. ¿Actualizar ahora o esperar a la 7.1?

El proyecto ya ha anunciado que la 7.1 será la próxima release mayor. La pregunta razonable es si conviene esperarla.

Nuestra recomendación depende de dónde estés. Si estás en 5.1, no esperes: estás sin soporte, y el camino recomendable pasa por 6.1 cuanto antes. Si estás en 6.0 o 6.1 y no necesitas webhooks de forma inmediata, puedes planificar el salto a 7.0.1 con calma durante los próximos meses; ambas ramas siguen recibiendo parches. Si lo que te interesa son los webhooks o el soporte RTL, la 7.0.1 ya está madura —lleva un ciclo de correcciones encima— y esperar solo retrasa el beneficio.

La respuesta que casi nunca es buena es «ya lo veremos el año que viene». Es la que convierte una actualización de una tarde en un proyecto de migración con presupuesto propio.

Conclusión

Redmine 7 es la release que responde a la pregunta de si el proyecto sigue vivo: webhooks nativos que eliminan una capa entera de plugins y polling, migración a Rails 8 y soporte para Ruby 4, una interfaz que por fin no parece de otra década y una limpieza de dependencias que facilitará las actualizaciones futuras. Veinte años después de la primera versión, el proyecto sigue tomando decisiones técnicas de fondo en lugar de limitarse a mantener lo que hay.

Para un responsable de IT, las conclusiones prácticas son tres. Primera: si estás en la rama 5.1, estás sin soporte desde junio y eso tiene fecha de caducidad operativa. Segunda: la versión a instalar es la 7.0.1, no la 7.0.0, por las cinco correcciones de seguridad de agosto. Tercera: el trabajo real de la actualización no está en el comando de despliegue, sino en el inventario de plugins, parches locales y versiones de Ruby y base de datos que lo preceden.

Hecho con orden —inventario, entorno de pruebas, backup restaurado y verificado, ventana de mantenimiento y vuelta atrás preparada—, es una actualización perfectamente asumible. Hecha con prisa un viernes por la tarde, es la historia que se cuenta en la retrospectiva del mes siguiente.

Preguntas frecuentes sobre Redmine 7

¿Cuándo salió Redmine 7 y qué versión debo instalar?

Redmine 7.0.0 se publicó el 30 de junio de 2026. La versión que debes instalar hoy es 7.0.1, del 26 de agosto de 2026, que corrige cinco problemas de seguridad e incorpora Rails 8.1.3.1.

¿Redmine 5.1 sigue recibiendo parches?

No. La rama 5.1 alcanzó su fin de vida con la 5.1.13 del 15 de junio de 2026. Las correcciones de seguridad de agosto se publicaron para 7.0, 6.1 y 6.0, pero no para 5.1.

¿Qué versión de Ruby necesito para Redmine 7?

Redmine 7.0 admite Ruby 3.2, 3.3, 3.4 y 4.0. Si eliges Ruby 4, usa la 4.0.4 o posterior: las versiones 4.0.0 a 4.0.3 tienen una regresión que ralentiza mucho el renderizado del wiki.

¿Los webhooks vienen activados por defecto?

No. Un administrador debe habilitarlos explícitamente y configurar los endpoints. Una instalación actualizada no empieza a emitir tráfico saliente por su cuenta.

¿Se puede saltar directamente de Redmine 5.1 a 7.0?

Técnicamente es posible, pero implica atravesar dos versiones mayores de Rails (6.1 a 8.1) de una vez, con el riesgo correspondiente en plugins y parches locales. En instalaciones con plugins recomendamos hacerlo en dos etapas, pasando por 6.1.

¿Mis plugins van a seguir funcionando?

Los que no hayan sido actualizados para Rails 8.1, probablemente no. El inventario de plugins es el primer paso de cualquier plan de actualización, y conviene hacerlo antes de comprometer una fecha con el equipo.