Com as ferramentas de launcher atuais e essa nova estrutura de branches, você poderia ter controle sobre o tempo de atualização fazendo algo como:
- v2026.02 lançado
- Você define
version: release/v2026.02no seu arquivo app.yml - v2026.03 lançado
- Você executa uma reconstrução. Você ainda obtém 2026.02, com quaisquer correções de segurança recentes
- Quando estiver pronto, você muda para
version: release/v2026.03em app.yml
Mas editar manualmente esse app.yml todo mês realmente não é o ideal, então esperamos poder projetar um sistema que torne o processo mais amigável ao usuário.
O processo na OP nos permite tratar os branches como ‘candidatos a lançamento’ antes de realmente marcá-los como um lançamento. Não tenho certeza exatamente se/como usaremos essa capacidade neste estágio - acho que é algo que evoluirá à medida que nos acostumarmos com o novo sistema.
Estamos tentando encontrar um equilíbrio aqui entre a velocidade de desenvolvimento do Discourse e a estabilidade para pessoas com personalizações extensas. Ter um atraso de mais de 3 meses para que os recursos cheguem aos nossos clientes não é uma opção. Na verdade, o mensal está no lado lento para nós. No momento, ainda pretendemos usar latest para a maioria de nossos hospedagens.
Mas, é claro, para pessoas que hospedam o Discourse, entendo o desejo de ter mudanças menos frequentes. É aí que entram os lançamentos ESR.