Avec les outils de lancement actuels et cette nouvelle structure de branches, vous pourriez contrôler le moment des mises à niveau en faisant quelque chose comme ceci :
- v2026.02 publiée
- Vous définissez
version: release/v2026.02dans votre fichier app.yml - v2026.03 publiée
- Vous exécutez une reconstruction. Vous obtenez toujours la version 2026.02, avec les correctifs de sécurité récents.
- Lorsque vous êtes prêt, vous passez à
version: release/v2026.03dans app.yml
Mais modifier manuellement ce app.yml chaque mois n’est vraiment pas idéal, nous espérons donc pouvoir concevoir un système qui rendra le processus plus convivial.
Le processus décrit dans le message initial nous permet de traiter les branches comme des « candidats à la publication » avant de les marquer comme une publication. Je ne suis pas sûr exactement si/comment nous utiliserons cette capacité à ce stade - je pense que c’est quelque chose qui évoluera à mesure que nous nous habituerons au nouveau système.
Nous essayons de trouver un équilibre entre la vélocité du développement de Discourse et la stabilité pour ceux qui ont des personnalisations étendues. Avoir un délai de 3 mois ou plus pour que les fonctionnalités parviennent à nos clients n’est pas une option. En tout cas, mensuellement est plutôt lent pour nous. Pour le moment, nous avons toujours l’intention d’utiliser latest pour la majorité de notre hébergement.
Mais bien sûr, pour les personnes qui hébergent Discourse elles-mêmes, je comprends le désir d’avoir des changements moins fréquents. C’est là qu’interviennent les publications ESR.