Qué saber antes de actualizar de v3.4.0 a v2026.7.2

Soy responsable de una instalación de Discourse basada en Docker que se ejecuta en Ubuntu y que heredé como parte de un proyecto de código abierto. Durante años, la actualizaba mediante git pull && ./launcher rebuild app y luego a través de la interfaz de administración en /admin/update. Sin embargo, dejé de actualizar de manera tan casual después de una experiencia dolorosa durante una actualización incompatible causada por docker_manager en enero de 2024 (ver los comentarios en el commit aquí y el commit revertido aquí).

Han pasado 2,5 años y necesito retomar el ritmo de actualizaciones, pero todavía me siento un poco nervioso por la última actualización que se rompió. Lo que me gustaría entender es qué debería saber antes de intentar actualizar de v3.4.0 a v2026.7.2. Nuestro sitio no utiliza plugins adicionales y la única configuración especial de la que tengo conocimiento es que usamos una URL de Discourse Connect para tener SSO con nuestro sitio principal de la comunidad.

¿Es tan simple como?

cd /var/discourse
git pull
./launcher rebuild app

Y luego actualizar a través de la interfaz de administración? ¿Hay algún paso intermedio del que deba estar al tanto al pasar de v3.4.0 a v2026.7.2?

Gracias,

Cory

O … (dado que estás nervioso) … haz una copia de seguridad (de todos modos) y configura un servidor completamente nuevo, restaura la copia de seguridad y luego redirige el dominio al nuevo servidor una vez que hayas terminado.

Lo único grande con lo que te encontrarás es que hay una actualización importante de Postgres (a la versión 18). Si construyes un servidor nuevo, no tendrás que lidiar con ese proceso de actualización.

También existe un pequeño riesgo de que los plugins o componentes de tema en los que dependes no hayan sido mantenidos, especialmente si están escritos por terceros menos activos.

La nerviosidad es la razón por la que los administradores de sistemas (SA) de Discourse experimentados utilizan una configuración de dos contenedores, para que puedas iniciar las actualizaciones antes de confirmarlas (aunque eso no ayuda tanto cuando tienes una gran actualización de Postgres, pero estas ocurren con poca frecuencia).

Gracias por tu respuesta. Me gusta esta idea y ¡voy a intentarlo!

Intenté la migración hoy y, una vez más, me topé de inmediato con un cambio que rompe la compatibilidad en la rama principal de discourse_docker:

Este commit hace que las compilaciones fallen y rompe la instalación/configuración, pero se fusionó en la rama principal de todos modos. Era exactamente esto de lo que me preocupaba.

Al ejecutar ./launcher bootstrap app, el resultado es:

rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean?  assets:precompile

¿Cómo es posible que se fusionen cambios que rompen la compatibilidad de esta manera en la rama principal, que se proporciona como parte de las instrucciones oficiales de instalación? ¿Se ignoran los fallos de compilación? El mismo error que estoy viendo está justo ahí en el registro de fallos:

Pude hacer un checkout de un commit anterior que me permitió continuar con los pasos de migración, pero ahora llevo dos actualizaciones consecutivas rotas por commits no probados fusionados en la rama principal.

Hola @corywright, lo siento por eso - el ESR actual no tiene ese trabajo, el parche está en camino aquí.

Lo solucionaremos pronto y me aseguraré de que el objetivo ESR se añada como objetivo de prueba de humo para prevenir futuras regresiones.

Gracias de nuevo por sugerir esta opción en lugar de una actualización in situ. Funcionó mucho mejor y me permitió empezar con una copia limpia de un nuevo sistema operativo.