Con las herramientas actuales del lanzador y esta nueva estructura de ramas, podrías tener control sobre el momento de la actualización haciendo algo como:
- Se lanza v2026.02
- Estableces
version: release/v2026.02en tu archivo app.yml - Se lanza v2026.03
- Ejecutas una reconstrucción. Todavía obtienes 2026.02, con las correcciones de seguridad recientes.
- Cuando estés listo, cambias a
version: release/v2026.03en app.yml
Pero editar manualmente ese app.yml cada mes no es ideal, así que esperamos poder diseñar un sistema que haga el proceso más fácil de usar.
El proceso en el OP nos permite tratar las ramas como “candidatos a lanzamiento” antes de marcarlos realmente como un lanzamiento. No estoy seguro de si/cómo usaremos esa capacidad en esta etapa; creo que es algo que evolucionará a medida que nos acostumbremos al nuevo sistema.
Estamos tratando de encontrar un equilibrio entre la velocidad de desarrollo de Discourse y la estabilidad para las personas con personalizaciones extensas. Tener un retraso de más de 3 meses para que las funciones lleguen a nuestros clientes no es una opción. En todo caso, el lanzamiento mensual es un poco lento para nosotros. En este momento, todavía tenemos la intención de usar latest para la mayoría de nuestros alojamientos.
Pero, por supuesto, para las personas que alojan Discourse por sí mismas, entiendo el deseo de tener cambios menos frecuentes. Ahí es donde entran los lanzamientos ESR.