Discourseのリリースチャンネル/バージョン間を切り替える

:bookmark: このガイドでは、Discourse インスタンスのリリースチャネルの設定方法について説明します。

:person_raising_hand: 必要なユーザーレベル:システム管理者

:warning: コンソールへのアクセスが必要です。

Discourse インスタンスのチャネルを管理することで、受信するアップデートの頻度や種類を決定できます。このガイドでは、利用可能なチャネルについて説明し、設定のブランチを変更するための手順を段階的に示します。

まとめ

Discourse は、ソフトウェアのアップデートを追跡するためのいくつかのチャネルを提供しています:latestrelease、および esr。このドキュメントでは、各チャネルの目的、主要な特徴、および Discourse インスタンスでの設定方法について説明します。チャネルの概要については、releases.discourse.org を参照してください。

サポートされているチャネル

latest

:information_source: 推奨デフォルト
このチャネルは、最新のバグ修正とプラグインの互換性アップデートを提供します。main ブランチからのすべてのコミットは、ビルドサーバーによってテストされ、検証に成功した後、latest ブランチに追加されます。

  • 常に最新の状態を維持したいサイトに適しています。
  • サイトはいつでも手動でアップデートできます。

release

:information_source: 月次リリースを好むサイト向け

release チャネルは、Discourse の最新の月次リリースを追跡します。毎月、latest からリリースブランチ(例:release/2026.2)が切り出され、安定したスナップショットが提供されます。

  • およそ1か月に1回リリースされます。
  • 各リリースは、2つの完全なリリースサイクルにわたり重要な修正を受け取ります。

esr

:information_source: 拡張サポートリリース

esr タグは、頻繁なアップデートよりも長期的な安定性とセキュリティを優先するサイトを対象とした、最新の拡張サポートリリースを追跡します。

  • 月次リリースからおよそ6か月に1回宣言されます。
  • 長い期間にわたりセキュリティ修正および重要なバックポートを受け取ります。
  • コミュニティプラグインやテーマコンポーネントとの互換性が限られている場合があります。

:warning: 注意: 定期的なメンテナンスアップデートを受信しない場合、一部の機能が時代遅れになったり、視覚的に一貫性がなくなったりする可能性があります。

非推奨のエイリアス

後方互換性のために、以下の古いブランチ/タグ名は依然として機能しますが、非推奨とされています。

  • tests-passedlatest
  • betarelease
  • stableesr

その他のブランチまたは参照

:warning: その他のブランチ(特定の release/YYYY.M ブランチやコミットSHAなど)を追跡することは可能ですが、専門知識が必要です。これらのブランチは、限られた期間のみ重要な修正を受け取ります。

チャネルの設定手順

Discourse インスタンスで希望するブランチを設定するには、以下の手順に従ってください。

  1. 設定ファイルにアクセス
    コンソールで以下のコマンドを実行して、app.yml 設定ファイルを開きます。
cd /var/discourse
nano containers/app.yml

nano エディタが設定ファイルを開きます。
2. 追跡ブランチを編集
ファイル内で “version” という単語を検索し、バージョンパラメータを見つけます。

params:  
## Which Git revision should this container use? (default: latest)  
#version: latest
  • バージョン行のコメントアウトを解除します。
  • latest を希望するブランチまたはタグ名(例:esr)に置き換えます。例:
params:  
## Which Git revision should this container use? (default: latest)  
version: esr  
  1. 保存して終了
  • Ctrl+O を押して変更を保存します。
  • Enter を押して確認します。
  • Ctrl+X を押してエディタを終了します。
  1. コンテナを再構築
    変更を適用し、保存した後、コンテナを再構築して新しい設定を適用します。
./launcher rebuild app

:warning: 再構築により一時的なダウンタイムが発生します

「いいね!」 27
Is it possible to upgrade Discourse up to a number of commits in the version?
How to avoid Discourse BETA version and keep only stable?
Upgrade Button - Possible Window to Exploits
Need a better way to explain what branch to be on, why, and what happens
Restoring Discourse 1.9 backup onto v2.3.0.beta9 +184
Cannot reorder categories
Download My Posts failed
Quote-feature occasionally missing on Android
What’s the best/safest branch not break production site?
How to change the target channel from DEV to BETA?
I need help to edit the sidebar
Help us test the rewritten Composer
Upcoming changes to the beta branch of Discourse
502 Bad Gateway after trying to rebuild test-passed branch
Stuck at v2.9.0.beta1 – Now Running 3.4.0.beta4-dev after Disabling Hooks: How Can I Lock to Stable Releases?
Have I Installed the wrong version? - 3.5.0.beta2-dev
Need a better way to explain what branch to be on, why, and what happens
Error 500 after Update
Landing Pages Plugin :small_airplane:
Self-hosted discourse instance appending "7d" to the FQDN
Update “3.4.0.beta4” failed
Issues with Discourse 3.5.0.beta2-dev - SMTP and Background Jobs
Install production ready stable on vps
Help deploying older versions of Discourse
[solved] How to avoid getting -dev versions when updating?
Production upgrades - correct procedure to follow
Production upgrades - correct procedure to follow
Problem with Upgrade [error 137]
ESR Usage Help
Is it possible to disable Discourse updates?
Is it possible to disable Discourse updates?

4 つの投稿が既存のトピックに統合されました: Discourse の旧バージョンのデプロイに関するヘルプ

git pull は必須のステップでしょうか? それとも、Discourse の更新の場合(Manually update Discourse and Docker image to latest )と同様に、レガシーなドキュメントから残っている冗長なステップでしょうか?

私の経験では、git pullときどき 役に立ちます。例えば、yarn から pnpm へ移行した際には必須でした…

通常、定期的な再構築のために手間をかける必要はありません。

「いいね!」 2

知っててよかったです!情報ありがとうございます。

私が普段 :sweat_smile: していることは、再構築を試みることです。そして、あまり明確でない理由で失敗した場合は、まず git pull を実行してみます。少し時間がかかります。

理論的には、これが必要になることは決してないはずです。ランチャーは古くなったコピーを自動的に検出し、自身で git pull を実行します:

「いいね!」 1

詳細な情報、ありがとうございます。確かに理にかなっていますね。git pul を使わずに試してみて、結果をお知らせします。

「いいね!」 1

奇妙ですね。問題のコードは2015年のもの、私のフォーラムは2018年のものですが、ここで git pull の必要性が何度か議論された事例があったと確信しています。

私自身、覚えていれば常に git pull を実行します。これにコストはかかりませんから。

非常に歴史的なこれらの文書のためか、よく言及されていますね。実際に役に立ったという証拠を見たことは、多分ありません。

でも、手動で実行しても害はありませんよ :person_shrugging:

「いいね!」 1

YML ファイルが supported tracking branch ではなく version を使用しているため、トピックのタイトルに (version) を追加するのは良いアイデアでしょうか?

最初は日付に少し驚きました。しかし、バージョン履歴を確認すると、最新のアップデートは5月18日です。

OP を更新して、最新の「チャンネル」用語を使用し、不要な git pull の参照をいくつか削除する提案を行いました。

「いいね!」 1

少なくとも境界ケースが存在するはずです。なぜなら、非常に稀なケースで確かに「私を乗り越えさせてくれた」からです。

メインスクリプトが限られた状況で変更される時でしょうか?

「いいね!」 1