RFC：Discourse の新しいバージョン管理戦略

開発
1

Discourse の新しいバージョン管理システムを導入する予定です。目標は、開発の勢いを維持しながら、コミュニティ管理者にさらに多くの選択肢と予測可能性を提供することです。また、他のソフトウェアとの連携を改善するために、いくつかの用語を調整します。

このドキュメントは、コメントを受け取り、システムの実装を開始し、新しいリリースストリームの使用を拡大するにつれて進化します。

この段階でコメントや提案があれば、このトピックに返信してお知らせください！

目標

  1. 開発速度と安定性のバランスをとる、より定期的な Discourse の「リリース」を導入する
  2. 長期間サポートされる約6ヶ月ごとのリリースを引き続き提供する
  3. 定期リリースと長期サポートリリースの両方を並行してサポートし、管理者がアップデートのタイミングについてより柔軟に対応できるようにしつつ、重要なセキュリティアップデートも引き続き受け取れるようにする
  4. 「リリース」に関する儀式を最小限に抑える。可能な限り自動化し、コア開発者のエクスペリエンスを低下させないようにする。ESR リリースは他のリリースと同じです。
  5. 名前と手順は業界標準に合わせ、開発者とエンドユーザーに説明しやすくする

全体概要

  • 月に約1回のリリースをカットします。「メジャー」バージョンは現在の年、「マイナー」バージョンは各リリースでインクリメントされます。パッチバージョン番号は、バックポートされた修正ごとにインクリメントされます。

    例：2026 年最初のリリースは v2026.0、次は v2026.1 などになります。

    リリースは、2つの完全なリリースサイクルで重要な修正を受け取ります。例：2026.0 のサポートは 2026.2 がリリースされるまで継続されます。

  • 約6ヶ月ごとに、それらのリリースの中から 1 つを長期サポートリリース（ESR）として宣言します。ESR バージョンは、次の ESR が宣言された後、2 つのリリースまでサポートされます。

    例：v2026.0 が ESR で、v2026.6 が次の ESR の場合、v2026.0 のサポートは v2026.8 がリリースされると終了します。月次ペースを仮定すると、ESR サポートの重複は 2 ヶ月になります。

  • latest、直近のリリース、前のリリース、およびアクティブな ESR バージョンに対して重要な修正を提供します。

  • tests-passed ブランチを latest にリネームします。

1 年間のサポート期間の例グラフ：

gantt
    title Discourse Releases and Support Periods (Jan 2026 – Jan 2027)
    dateFormat  YYYY-MM-DD
    axisFormat  %b %Y

    2026.0 (ESR) :active, 2026-01-27, 2026-09-29
    2026.1 :done, 2026-02-24, 2026-04-28
    2026.2 :done, 2026-03-31, 2026-05-26
    2026.3 :done, 2026-04-28, 2026-06-30
    2026.4 :done, 2026-05-26, 2026-07-28
    2026.5 :done, 2026-06-30, 2026-08-25
    2026.6 (ESR) :active, 2026-07-28, 2027-01-26
    2026.7 :done, 2026-08-25, 2026-10-27
    2026.8 :done, 2026-09-29, 2026-11-24
    2026.9 :done, 2026-10-27, 2026-12-29
    2026.10 :done, 2026-11-24, 2027-01-26
    2026.11 :done, 2026-12-29, 2027-01-26

実装

  • 各リリースは latest からカットされたブランチを持ちます。これらは名前空間化され、無期限に保存されます。例：v2026.1 は release/2026.1 という名前のブランチを持ちます。

  • 各パッチリリースはタグ付けされます。例：v2026.1.0、v2026.1.1 など。

  • 最新リリースは release タグ付けされます。最新の ESR は esr タグ付けされます。

  • 前のリリースは release-previous タグ付けされます。前のアクティブな ESR（もしあれば）は esr-previous タグ付けされます。

  • 後方互換性のために、既存のリリースストリームと一致するタグは、最も近い新しい同等物にエイリアスされます。stable → esr。beta → release。tests-passed → latest。

    これらは非推奨と見なされ、将来的には一部またはすべてを削除することを目指します。特に「beta」は、Discourse が本番環境に対応していないという印象を与えるため問題があります。

  • latest では、バージョン番号は開発中のバージョンに -latest を付加したものになります。例：2026.3.0-latest

自動リリースプロセス

毎月、GitHub アクションが新しい PR を開き、main の version.rb を次の -latest バージョンに引き上げる単一コミットを含みます。

人間が PR をマージすると、別の GitHub アクションが main が次の -latest に移動したことを検出し、完了したリリースのブランチをカットします。基本的に、このブランチは「リリース候補」になります。別の自動 PR がリリースブランチに対して開き、version.rb から -latest サフィックスを削除して「リリース」します。

通常、これらの 2 つの PR はすぐにマージしますが、リリース作成と最終化のための別々の PR を持つことで、最終化前にブランチの問題に対処するオプションが得られます。

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       checkout main
       commit id:'version v2026.1-latest'
       commit id:'...'
       commit id:'....'
       branch 'release/2026.1'
       commit id:'version 2026.1'
       checkout 'main'
       commit id:'version v2026.2-latest'

別途、別の GitHub アクションワークフローが、リリースブランチへのバックポートされたコミットを監視します。それらが見つかると、そのブランチのパッチバージョンを引き上げる PR が生成されます。人間がそれらの PR をいつマージするかを決定できます。

これらのすべての自動化により、さまざまなタグ（release、release-previous、esr、esr-previous、および後方互換性エイリアス）が自動的に最新の状態に保たれます。

セキュリティ修正

セキュリティ修正ワークフローはほぼ同じですが、これらの 3 つの新しい場所のうち 2 つで修正を行う必要があります。

  • latest

  • esr

  • esr-previous :new_button:

  • release :new_button:

  • release-previous :new_button:

（前の図によると、3 つのうち 2 つだけです。esr-previous はサポートされており、新しい esr は release または release-previous と同じであり、それが当てはまらなくなると esr-previous のサポートを削除するためです。）

latest にセキュリティ修正を導入すると、latest-security-fix タグがそのコミットに自動的に移動します。docker_manager はそのタグを監視するように更新され、管理者にアップデートを促します。これにより、バージョンの引き上げを急ぐことなく、セキュリティ修正をリリースし、通知することができます。

翻訳

現在、stable および tests-passed ブランチは CrowdIn で翻訳でき、結果は定期的に統合されています。新しいシステムでは、当初は latest および release を CrowdIn で翻訳できるようにする予定です。

理想的には、release が release-previous または esr になるまでに、翻訳は落ち着いているでしょう。それらのバージョンの継続的な翻訳の需要がある場合は、将来的に検討される可能性があります。

プラグイン/テーマの互換性

Discourse の latest ストリーム以外のストリームの使用を増やすと、discourse-compatibility システムへの依存度が高まります。そのため、互換性システムにいくつかの改善が必要です。

main 上の .discourse-compatibility ファイルを使用する代わりに、特別に名前が付けられたブランチ/タグに基づいた暗黙的な互換性をサポートできるようになります。これは、コミットハッシュを手動で調整するよりもはるかに簡単になるはずです。たとえば、プラグインには次のようなブランチを持たせることができます。

  • d-compat/v2026.1
  • d-compat/v2026.2
  • d-compat/v2026.3
  • main （独自のブランチを持たない Discourse バージョンに使用）

プラグインをインストールする際、Discourse は現在のバージョンに一致するブランチをチェックできます。存在する場合は、それをチェックアウトします。存在しない場合は、.discourse-compatibility ファイルをチェックします。それ以外の場合は、デフォルトのブランチをチェックアウトします。

各テーマ/プラグインで毎日実行され、新しい Discourse リリースをチェックし、これらのブランチを自動的に作成する公開 GitHub アクションを作成できます。各テーマ/プラグインは、この自動ピン留めアクションを使用するか、より「フローティング」戦略を選択できます。

discourse.org ホスティング

当初、当社のホスティングサービスは引き続き Discourse の latest バージョンを実行します。将来的には、エンタープライズティアの顧客が「リリース」バージョンを選択できるオプションを検討します。

標準インストールのデフォルト

当初、デフォルトは latest のままです。管理者は、現在 stable をオプトインしているのと同じ方法で、新しいリリースストリームをオプトインできるようになります。システムがより成熟したら、将来的にリリースストリーム間の簡単な切り替えを検討する可能性があります。

「いいね！」 38
3

混乱しています。つまり、tests-passed（latestとしても知られる）は最も最新（最も頻繁に更新される）になり、現在のbetaブランチ（現在はreleaseブランチ）は現在と同じように動作し続ける、つまり「コミット/更新のグループ」であり、ESR（stableとしても知られる）はbeta/releaseの更新のより大きな「グループ」になるということでしょうか？

これは、releaseがデフォルトオプションになるということでしょうか、それとも「releaseブランチの最新アップデート」を指しているのでしょうか？その場合、latestとの違いはありますか？

よろしくお願いします！

「いいね！」 1
4

betaは現在タグであり、バックポートされた修正は受け取りません。

この提案により、バージョン管理された各リリースには独自のブランチが作成され、「サポートされている」限りセキュリティ修正を受け取ります。ユーザーは、特定のバージョン番号をインストール先に指定し、別のリリースが行われた後もそれを使用し続けることができます。これは、現在のbetaまたはstableでは不可能です。

releaseは、セキュリティ修正のために最新リリース（パッチリリースを含む）に続くタグになります。

いいえ：

「最新リリース」（または単に「リリース」）=最新リリースブランチの最新コミット

「latest」= tests-passedの新しい名前

「いいね！」 3
5

ありがとうございます、これで分かりました！

「いいね！」 2
6

これは前向きな進展のようですね！

esrがラベル付けされる際に、esr-previousからesrへのアップグレードの特別なテストはありますか？そのようなアップグレードは、スムーズなアップグレードになるように、または可能な限りスムーズに実行する方法の良い説明があるように手配されるべきだと私は主張します。

「いいね！」 4
7

はい、ESR バージョン間（またはサポートされている任意のバージョン間）のアップグレードは引き続きシームレスに行われます。

「いいね！」 2
8

利便性のために小さなリクエストですが、ポインタ（例：2026.0）をリリースがプッシュされた月に紐付けることはできませんか？（つまり、1月は2026.01、2月は2026.02など）

「いいね！」 4
9

月ごとに明示的にリリースを紐付ける問題点は、ある月をスキップしたり、月に2つのバージョンをリリースしたりできなくなることです。そのため、単純な連番を維持する予定です。

「いいね！」 3
10

私がヘビーユースしているプロジェクト（mailcow）は、コアに大きな変更がない月はスキップします。

そして、0から数えるのは非常に奇妙です。プログラマーにとっては理にかなっていますが、非技術的な人々にとってはあまり意味がありません。

「いいね！」 2
11

x.0リリースについて気になっていました。リリースされた時期がすぐにわかるように月と結びつけるのはとても良いと思いますが、xx.8が9月、12月、または6月にリリースされたかどうかは関係ないかもしれません。今どのリリースを使っているのかさえほとんど覚えていませんが、コミットを確認しなくても、先週のバグなのか、数ヶ月前のバグなのかをすぐに判断できれば、とてもありがたいです。

UbuntuにはYY.04とYY.10があります。これは20年間うまくいっています。月をスキップするのは難しくないようです。

それはもっと問題のように思えますが、もし月に2つのリリースが必要な場合は、22.1aや22.01aのようなものを使用することもできます。

「いいね！」 6
12

しばらく前に、私たちのプラットフォームでもこの戦略を使用し始めました。ブランチとパッチもまったく同じです。お勧めできます。

月次リリースを使用しています。したがって、1〜12です。このリズムは皆に役立ちます。常にリリースできるものがあり、誰も月に2回もブランチをカットしたくないでしょう。また、「2025.6を使用しています」と言うと、誰もがそれが夏休み前のものだとわかります。

「いいね！」 7
13

まず、:rocket:素晴らしい一歩です！

この件について少し考えたのですが、マイナーな指摘が2つあります。

  1. git branch やその他の多くのツールはバージョン管理を理解せず、アルファベット順または数字順にソートします。どちらの場合も、2026.10 は 2026.1 と 2026.2 の間に配置されます。Ubuntu に触発されて、リリースとパッチリリースが1桁の場合、先頭にゼロを追加することを提案します。これにより、v2026.01、v2026.02、v2026.10 となり、すべてがうまくいくようになります。

  2. 新しいプラグイン互換性方法は、過度に複雑で非常に壊れやすいように思えます。

つまり、プラグインで v2026.3 が必要な新しい機能をビルドする場合、ブランチを作成してそこに新しい機能を追加します。機能がビルドされ、クライアントが満足したら、休憩して休暇を楽しむことができます :palm_tree: :wine_glass: 。しかし、ワインを3杯飲んだ後、v2026.4 がリリースされ、クライアントがアップデートすることにしました。すると、私のプラグインに v2026.4 ブランチがなく、機能が消えてしまいます :sob: 。

そのため、私はこれを使用せず、代わりに .discourse-compatibility を使い続けます。

「いいね！」 9
14

意図は逆です。互換性ブランチは、リリース済みのDiscourseブランチ専用です。Discourseのlatestは常にプラグインのmainを使用します。そこに新機能を開発します。

したがって、ストーリーは次のようになります。

Discourseがv2026.2をリリースします。プラグインのGitHubアクションがこれを自動的に検出し、d-compat/v2026.2ブランチを作成します。これで、Discourse v2026.2を使用している人は誰でも、プラグインのd-compat/v2026.2バージョンを使用することになります。

プラグインのmainに新機能をリリースします。後方互換性を気にする必要はありません。なぜなら、mainブランチはDiscourse latestを実行している人だけが使用するからです。

その後、ワインを3杯飲んでいる間 :wine_glass: 、Discourseがv2026.3をリリースします。最初はプラグインのブランチがないため、mainが使用されます。latestを使用している人にとっては、これまで通り機能します。

数時間以内に、GitHubアクションが新しいバージョンを検出し、d-compat/v2026.3をフリーズし、次のプラグイン機能が後方互換性を気にせずにmainに配置される準備が整います。

これは、CDCKでテーマ/プラグインの安定した互換性を処理するために使用しているワークフローと基本的に同じです。各安定リリース後、数百のテーマ/プラグインを対象に、.discourse-compatibilityを介してフリーズするスクリプトを実行します。このブランチベースの提案は、そのワークフローの軽量版を目指しています。

「いいね！」 16
15

素晴らしいですね、詳しい説明をありがとうございます。

ワインをもう一杯飲めそうです :wink:

「いいね！」 15
16

他の皆さんが言っていることに賛成です。提案されている変更の方向性は気に入っています。また、提案されているブランチ名は古いものよりも直感的だと思います :+1:

まだ明確でないのは、release および esr ブランチのアップグレードプロセスがどのように機能するかです（latest は簡単そうです）。常に、現在のリリース（n と呼びましょう）と以前のリリース（n-1）の両方がサポートされ、管理者である私がアップグレードのタイミングを選択できると述べています。

他のソフトウェアでの経験から、新しいリリースバージョン（n+1）が到着したときに、バージョン n+1 の利用可能性について通知を受け取ります。そして、メジャーアップグレード（Linux の apt dist-upgrade に相当）を行うか、マイナー/標準アップデート（Linux の apt upgrade に相当）を行ってバージョン n に留まるかを選択できます。これは Discourse ランチャー スクリプトに組み込まれる予定ですか？

また、リリースセレモニー/プロセスを最小限に抑えたいという要望は理解できますが、通常リリースと esr リリースの両方に、リリース前に少なくとも少し追加のテストが行われることが直感的だと思います。それは、エンタープライズ IT で長すぎたためかもしれません :smile:

最後に、月次リリースは実際には「速すぎる」のではないかと疑問に思っています。これも主観的ですが、ボランティアとして IT 関連の管理をサイドで行ってきた自身の経験から判断すると、毎月大きなアップデートを行う時間が取れないかもしれません。そこから、Discourse の開発者としての皆さんの生活を少しでも楽にするために、四半期ごとにリリースし、個別の esr ブランチは持たず、release ブランチのみにするという可能性も考えていました。

「いいね！」 4
17

それは、テーマやプラグインの開発者の生活をより困難にするでしょう。なぜなら、その（この）状況では、テーマやプラグインを更新しなければならないという時間的なプレッシャーがあり、そうでなければセキュリティアップデートを受けられなくなるからです。ESRバージョンは、そのプレッシャーを軽減します。

「いいね！」 4
18

完全には理解できていないのですが。以前の投稿に基づくと、リリースバージョンのブランチを作成すると、そのバージョン用のプラグインブランチが自動的に作成されるということでした。したがって、releaseとesrを1つにマージすることで、プラグインやテーマの作成者の労力も軽減されると想定していました。なぜなら、修正をプッシュする必要があるたびに、より少ないブランチ（5つではなく3つ）にプッシュする必要があるからです。しかし、何か見落としていることがあるのでしょうか？

「いいね！」 2
19

テーマ/プラグインの作者が修正をプッシュするタイミングではなく、Discourse コアがセキュリティ修正を行うタイミングが重要です。

release と esr の唯一の違いは、esr が 6 + 2 = 8 ヶ月間セキュリティ修正を受け取ることです。

「いいね！」 1
20

現在のランチャーツールとこの新しいブランチ構造を使用すると、次のような方法でアップグレードタイミングを制御できます。

  1. v2026.02 がリリースされる
  2. アプリケーションの app.yml ファイルで version: release/v2026.02 を設定する
  3. v2026.03 がリリースされる
  4. 再ビルドを実行する。セキュリティ修正が含まれた 2026.02 が引き続き取得される
  5. 準備ができたら、app.yml で version: release/v2026.03 に切り替える

しかし、毎月 app.yml を手動で編集するのは実際には理想的ではないため、プロセスをよりユーザーフレンドリーにするシステムを設計できることを願っています。

OP のプロセスでは、ブランチを実際にリリースとしてマークする前に「リリース候補」として扱うことができます。現時点では、その機能がどのように使用されるかについては正確にはわかりません。新しいシステムに慣れるにつれて進化していくものだと思います。

ここでは、Discourse の開発速度と、広範なカスタマイズを行っているユーザーの安定性のバランスを取ろうとしています。顧客に機能を提供するのに 3 か月以上遅延するのは選択肢ではありません。むしろ、月次リリースは私たちにとっては遅い方です。現時点では、ホスティングの大部分で latest を使用する予定です。

しかし、もちろん、Discourse を自分でホスティングしているユーザーにとっては、より頻繁な変更がないことを望む気持ちは理解できます。そこで ESR リリースが登場します。

「いいね！」 5
21

これはプラグイン/テーマの作成者次第です。現在の戦略を継続し、プラグインの main ブランチがすべての「リリース済み」バージョンの Discourse で動作するようにするか、自動ブランチ戦略を使用するかです。後者は互換性を容易にしますが、重要なバグ/セキュリティ修正の場合にプラグインで多くの「バックポーティング」が必要になる可能性があります。

常に 3 つの「サポートされている」バージョンの Discourse と latest があります。したがって、重要な修正は最大 4 つのブランチに適用する必要があります。

「いいね！」 3