Con gli attuali strumenti del launcher e questa nuova struttura dei branch, potresti avere il controllo sui tempi di aggiornamento facendo qualcosa come:
- Rilasciata v2026.02
- Imposti
version: release/v2026.02nel tuo file app.yml - Rilasciata v2026.03
- Esegui una nuova build. Ottieni ancora la 2026.02, con eventuali correzioni di sicurezza recenti
- Quando sei pronto, passi a
version: release/v2026.03in app.yml
Ma modificare manualmente quel app.yml ogni mese non è davvero l’ideale, quindi speriamo di poter progettare un sistema che renda il processo più user-friendly.
Il processo nell’OP ci consente di trattare i branch come ‘release candidate’ prima di contrassegnarli effettivamente come release. Non sono sicuro esattamente se/come utilizzeremo tale capacità in questa fase: penso che sia qualcosa che si evolverà man mano che ci abitueremo al nuovo sistema.
Stiamo cercando di trovare un equilibrio tra la velocità di sviluppo di Discourse e la stabilità per coloro che hanno personalizzazioni estese. Avere un ritardo di oltre 3 mesi per portare le funzionalità ai nostri clienti non è un’opzione. Semmai, il mensile è un po’ lento per noi. Al momento intendiamo ancora utilizzare latest per la maggior parte del nostro hosting.
Ma ovviamente, per le persone che ospitano Discourse da sole, capisco il desiderio di avere cambiamenti meno frequenti. È qui che entrano in gioco le release ESR.