現在のランチャーツールとこの新しいブランチ構造を使用すると、次のような方法でアップグレードタイミングを制御できます。
- v2026.02 がリリースされる
- アプリケーションの
app.ymlファイルでversion: release/v2026.02を設定する - v2026.03 がリリースされる
- 再ビルドを実行する。セキュリティ修正が含まれた 2026.02 が引き続き取得される
- 準備ができたら、
app.ymlでversion: release/v2026.03に切り替える
しかし、毎月 app.yml を手動で編集するのは実際には理想的ではないため、プロセスをよりユーザーフレンドリーにするシステムを設計できることを願っています。
OP のプロセスでは、ブランチを実際にリリースとしてマークする前に「リリース候補」として扱うことができます。現時点では、その機能がどのように使用されるかについては正確にはわかりません。新しいシステムに慣れるにつれて進化していくものだと思います。
ここでは、Discourse の開発速度と、広範なカスタマイズを行っているユーザーの安定性のバランスを取ろうとしています。顧客に機能を提供するのに 3 か月以上遅延するのは選択肢ではありません。むしろ、月次リリースは私たちにとっては遅い方です。現時点では、ホスティングの大部分で latest を使用する予定です。
しかし、もちろん、Discourse を自分でホスティングしているユーザーにとっては、より頻繁な変更がないことを望む気持ちは理解できます。そこで ESR リリースが登場します。