古いDiscourseインストールでのプラグインとテーマのバージョン固定(d-compatブランチ)

:open_book: 背景

テーマやプラグインの開発者は、通常、Discourse の latest リリースを対象に開発し、後方互換性の心配を避けたいと考えています。しかし、古い Discourse リリースを実行しているサイトには、それに対応するテーマ/プラグインのバージョンが必要です。

このギャップを埋めるために、Discourse には、テーマ/プラグインの古い「ピン留め」バージョンをチェックアウトするよう指示することができます。これには2つの仕組みがあり、以下の順序でチェックされます:

  1. テーマ/プラグインのリポジトリにある d-compat/<YYYY>.<M> git ブランチ(主要な方法 — 新規のピン留めにはすべて推奨)。
  2. リポジトリのルートにある .discourse-compatibility YAML ファイル(元の仕組み、フォールバックとして引き続きサポート)。

両方が存在する場合、ブランチが優先されます。

:herb: d-compat/<YYYY>.<M> ブランチシステム

Discourse のリリースは 2025.52025.6 のような日付ベースのバージョンを使用します。Discourse が git からプラグインやテーマを更新する際、リポジトリに対して「自分のバージョンに一致する d-compat/<YYYY>.<M> という名前のブランチはありますか?」と問いかけます(例:Discourse 2025.5.x には d-compat/2025.5)。該当するブランチがある場合、Discourse は main の代わりにそのブランチの先端をチェックアウトします。

この検索は、ローカルでのチェックアウトがリポジトリの デフォルトブランチ にある場合のみ実行されます。意図的に他のブランチにピン留めしている場合、d-compat ロジックはスキップされ、あなたのピン留めが尊重されます。

このシステムで古い Discourse バージョンをサポートするには:

  1. そのバージョンで動作することが確認されているコミットから、d-compat/<YYYY>.<M> という名前のブランチを作成します(例:git checkout -b d-compat/2025.5 <commit>)。
  2. origin にプッシュします。誤って削除されないよう、ブランチを保護することを検討してください。
  3. バックポートコミットをそのブランチにマージします。2025.5.x の Discourse インスタンスは次の更新時にそれらを自動的に取得し、新しい Discourse のインスタンスはデフォルトブランチを継続して追跡します。

ブランチを使用する場合、.discourse-compatibility を変更する必要はありません。

:gear: 自動ブランチ作成(create-d-compat-branch.yml

実際には、これらのブランチを手動で作成する必要はほとんどありません。デフォルトのテーマやプラグインのスケルトンには、毎日実行され、Discore コアの新バージョンをチェックし、必要に応じて対応する d-compat/<YYYY>.<M> ブランチをプッシュする d-compat-branch.yml ワークフロー が含まれています。

リポジトリがスケルトンの古いコピーから作成された場合、d-compat-branch.yml ファイルを .github/workflows ディレクトリにコピーするだけで動作します。

:git_merged: d-compat ブランチへの修正のバックポート

デフォルトブランチにマージした修正が、古い Discourse リリースのサイトにも届く必要がある場合:

  1. 対象の d-compat ブランチから分岐し、修正をチェリーピックします:

    git fetch origin
    git checkout -b backport/my-fix-2025.5 origin/d-compat/2025.5
    git cherry-pick <commit-sha>
    git push -u origin backport/my-fix-2025.5
    
  2. ベースブランチd-compat/2025.5 に設定して PR を作成します(main ではありません)。他の PR と同じようにレビューとマージを行います。

  3. 修正が必要な各古い d-compat/<YYYY>.<M> ブランチに対して繰り返します。

2025.5.x のサイトは、次の更新時にマージされたコミットを取得します。

レガシーフォールバック:`.discourse-compatibility` ファイル

対応する d-compat ブランチが存在しない場合、Discourse はリポジトリのルートにある YAML の .discourse-compatibility ファイルにフォールバックし、Discourse バージョンをプラグイン/テーマの git リファレンスにマッピングします:

< 3.2.0.beta2-dev: abcde

Discourse は、実行中のコアバージョンに一致する最も低いエントリを選択するため、< 3.2.0.beta2-dev のユーザーはコミット abcde をチェックアウトします。バージョンの境界を指定するには <(または、オペレーターが指定されていない場合のデフォルトであるレガシーの <=)を使用します。これは、ブランチベースのシステムでは必要とされることを表現できない場合のみ使用してください。


このドキュメントはバージョン管理されています - 変更提案は github でお願いします。

「いいね!」 17

バージョンが 3.5.0.beta8-dev より小さい場合、3.5.0 は含まれますか?

No. 3.5.0 は、リリース候補版の「3.5.0.beta8-dev」よりも「大きい」と見なされます。

常に Ruby コンソールで比較を試すことができます。

> Gem::Version.new("3.5.0") < Gem::Version.new("3.5.0.beta8-dev")
=> false
「いいね!」 5

承知いたしました。説明ありがとうございます!

「いいね!」 1

このドキュメントは、Discourse の新しいバージョン管理戦略に関する RFC(https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536)で説明されている新しい d-compat/* 戦略について更新されました。この戦略は現在、利用可能です。

「いいね!」 5

d-compat/<YYYY>.<M>戦略では、各特定のリリースごとにブランチを作成する必要があるんですよね?.discourse-compatibility構成のように範囲指定はできません。

つまり、ESRから最新バージョンまで対応するプラグインをメンテナンスしている場合、開発を新しいESR(旧ESRと重複する)に移行する際に、中間バージョンごとにブランチを作成する必要があるということでしょうか?

例えば、現在ESRが2026.1、リリースバージョンが2026.6、最新バージョンが2026.7で、2026.5はまだサポートされているとします。Discourseがまだ旧ESRをサポートしている間に、プラグインを新しいESR(2026.7)に移行する場合、以下のブランチを作成する必要があるのでしょうか?

  • d-compat/2026.1
  • d-compat/2026.2
  • d-compat/2026.3
  • d-compat/2026.4
  • d-compat/2026.5
  • d-compat/2026.6

ここで、2026.2から2026.5(含む)はDiscourseによってEOL(サポート終了)になっていますが、ユーザーはまだ使用している可能性があります。

あるいは、特定のブランチが存在しない場合、Discourseはmainブランチを仮定するのではなく、最も適切なブランチを検索するのでしょうか?

例えば、2026.5を実行していて、存在するブランチがd-compat/2026.1d-compat/2026.6だけの場合、どのブランチが使用されるでしょうか?

  1. 最も近い互換性のあるバージョンであるd-compat/2026.1
  2. 特定のブランチがないため、main
「いいね!」 1

はい、Discourse コアの各バージョンごとに1つのブランチが必要です。作成を自動化することをお勧めします:

main が使用されます。

「いいね!」 2