Cambiar entre canales/versiones de lanzamiento de Discourse

:bookmark: Esta guía explica cómo configurar el canal de lanzamiento de tu instancia de Discourse.

:person_raising_hand: Nivel de usuario requerido: Administrador del sistema

:warning: Se requiere acceso a la consola.

Gestionar el canal de tu instancia de Discourse determina la frecuencia y el tipo de actualizaciones que recibes. Esta guía explica los canales disponibles y proporciona un enfoque paso a paso para cambiar la rama en tu configuración.

Resumen

Discourse ofrece varios canales para seguir las actualizaciones de software: latest, release y esr. Esta documentación explica el propósito de cada uno, sus características clave y cómo configurarlas en tu instancia de Discourse. Para una ilustración de los canales, consulta releases.discourse.org.

Canales compatibles

latest

:information_source: Predeterminado recomendado
Este canal proporciona las últimas correcciones de errores y actualizaciones de compatibilidad para los complementos. Cada commit realizado en la rama main es probado por el servidor de compilación y añadido a la rama latest tras una verificación exitosa.

  • Adecuado para sitios que desean mantenerse actualizados.
  • Los sitios pueden actualizarse manualmente en cualquier momento.

release

:information_source: Para sitios que prefieren lanzamientos mensuales

El canal release sigue el lanzamiento mensual más reciente de Discourse. Cada mes, se crea una rama de lanzamiento (por ejemplo, release/2026.2) a partir de latest, proporcionando una instantánea estable.

  • Se lanza aproximadamente una vez al mes.
  • Cada lanzamiento recibe correcciones críticas durante dos ciclos de lanzamiento completos.

esr

:information_source: Lanzamiento con soporte extendido

La etiqueta esr sigue el último Lanzamiento con Soporte Extendido, destinado a sitios que priorizan la estabilidad y seguridad a largo plazo sobre las actualizaciones frecuentes.

  • Se declara aproximadamente cada 6 meses a partir de los lanzamientos mensuales.
  • Recibe correcciones de seguridad y backports críticos durante un período extendido.
  • Puede tener compatibilidad limitada con complementos de la comunidad y componentes de temas.

:warning: Nota: No recibir actualizaciones de mantenimiento regulares puede dejar algunas funciones desactualizadas o visualmente inconsistentes.

Alias obsoletos

Por compatibilidad con versiones anteriores, los siguientes nombres antiguos de ramas/etiquetas siguen funcionando pero se consideran obsoletos:

  • tests-passedlatest
  • betarelease
  • stableesr

Otras ramas o referencias

:warning: Seguir otras ramas (por ejemplo, ramas específicas release/AAAA.M o SHAs de commit) es posible pero requiere experiencia. Estas ramas solo reciben correcciones críticas durante un período limitado.

Instrucciones para configurar tu canal

Sigue estos pasos para configurar la rama deseada en tu instancia de Discourse:

  1. Acceder al archivo de configuración
    Abre el archivo de configuración app.yml ejecutando los siguientes comandos en tu consola:
cd /var/discourse
nano containers/app.yml

El editor nano abrirá el archivo de configuración.
2. Editar la rama de seguimiento
Localiza el parámetro de versión buscando la palabra “version” en el archivo:

params:  
## ¿Qué revisión Git debería usar este contenedor? (predeterminado: latest)  
#version: latest
  • Descomenta la línea de versión.
  • Reemplaza latest con el nombre de la rama o etiqueta deseada (por ejemplo, esr). Ejemplo:
params:  
## ¿Qué revisión Git debería usar este contenedor? (predeterminado: latest)  
version: esr  
  1. Guardar y salir
  • Presiona Ctrl+O para guardar tus cambios.
  • Presiona Enter para confirmar.
  • Usa Ctrl+X para salir del editor.
  1. Reconstruir el contenedor
    Una vez realizados y guardados los cambios, reconstruye el contenedor para aplicar la nueva configuración:
./launcher rebuild app

:warning: La reconstrucción causará una interrupción temporal del servicio

27 Me gusta
Is it possible to upgrade Discourse up to a number of commits in the version?
How to avoid Discourse BETA version and keep only stable?
Upgrade Button - Possible Window to Exploits
Need a better way to explain what branch to be on, why, and what happens
Restoring Discourse 1.9 backup onto v2.3.0.beta9 +184
Cannot reorder categories
Download My Posts failed
Quote-feature occasionally missing on Android
What’s the best/safest branch not break production site?
How to change the target channel from DEV to BETA?
I need help to edit the sidebar
Help us test the rewritten Composer
Upcoming changes to the beta branch of Discourse
502 Bad Gateway after trying to rebuild test-passed branch
Stuck at v2.9.0.beta1 – Now Running 3.4.0.beta4-dev after Disabling Hooks: How Can I Lock to Stable Releases?
Have I Installed the wrong version? - 3.5.0.beta2-dev
Need a better way to explain what branch to be on, why, and what happens
Error 500 after Update
Landing Pages Plugin :small_airplane:
Self-hosted discourse instance appending "7d" to the FQDN
Update “3.4.0.beta4” failed
Issues with Discourse 3.5.0.beta2-dev - SMTP and Background Jobs
Install production ready stable on vps
Help deploying older versions of Discourse
[solved] How to avoid getting -dev versions when updating?
Production upgrades - correct procedure to follow
Production upgrades - correct procedure to follow
Problem with Upgrade [error 137]
ESR Usage Help
Is it possible to disable Discourse updates?
Is it possible to disable Discourse updates?

4 publicaciones se han fusionado en un tema existente: Ayuda para implementar versiones anteriores de Discourse

¿Es necesario el paso git pull o es redundante y proviene de la documentación antigua, al igual que en el caso de actualizar Discourse (Actualizar manualmente Discourse y la imagen de Docker a la última versión)?

Por experiencia, git pull es ocasionalmente útil, por ejemplo, fue imprescindible cuando cambié de yarn a pnpm…

Normalmente no necesitas preocuparte por una reconstrucción regular.

2 Me gusta

¡Qué bueno saberlo! Gracias por la información.

lo que suelo hacer :sweat_smile: es intentar reconstruir, y si falla por alguna razón no muy obvia, primero intento hacer un git pull - lleva un momento.

En teoría, nunca debería ser necesario. El lanzador detectará automáticamente una copia desactualizada y realizará el git pull por sí mismo:

1 me gusta

Gracias por los detalles. En efecto, tiene sentido. Lo intentaré sin git pul y te haré saber cómo funciona.

1 me gusta

Eso es extraño. El código en cuestión data de 2015, mi foro data de 2018, y sin embargo estoy bastante seguro de que aquí se han discutido varios casos en los que era necesario hacer git pull.

Por mi parte, siempre haré git pull, si me acuerdo; no me cuesta nada.

Se menciona mucho, creo que por estos documentos muy históricos. No creo haber visto nunca pruebas de que realmente ayude.

Pero sí, no hay ningún inconveniente en ejecutarlo manualmente también :person_shrugging:

1 me gusta

Dado que el archivo yml utiliza version y no supported tracking branch, ¿sería bueno añadir (version) al título del tema?

Al principio, la fecha también me sorprendió un poco. Pero, al revisar el historial de versiones, la última actualización es del 18 de mayo.

Hecho un intento por actualizar la publicación original para usar nuestra terminología moderna de “canal” y eliminar algunas de las referencias innecesarias a git pull.

1 me gusta

Debe haber al menos un caso extremo, porque definitivamente “me ha pasado el mal momento” en ocasiones muy raras

¿Podría ser cuando el script principal cambia en circunstancias limitadas?

1 me gusta