2026.1 でリリースされたすべての変更の詳細については、以下を確認してください。
これは Discourse の最初の「ESR」リリースであり、古い「stable」ブランチに取って代わります。stable を追跡しているサイトは、次回のアップグレード時に 3.5 から 2026.1 にアップグレードされます。3.5 から 2026.1 までのすべての変更を確認するには、こちらのリンクを使用してください。
その他のサポートされているバージョンのパッチリリースもリリースされています。
「いいね！」 12
2026.1.0 は最初の esr リリースでもあります。
以前から存在していた stable ブランチ（現在は esr にエイリアスされています）をご利用の方については、3.5.3 から 2026.1.0 に移行し、3.5.4 には移行しません。
「いいね！」 2
それでは、更新しない期限が4月まで（3ヶ月）で、v2026.1 が非推奨になる場合、私の現在のバージョンはESRになるということでしょうか？これらの変更は少し混乱します。
「いいね！」 1
はい、3.5に留まるためにv3.5.4タグを使用している場合を除きます。
https://releases.discourse.org/ のホームページにある図が、物事を視覚化する最良の方法です。
どのリリースストリームを選択するにしても、重要なセキュリティ修正のためには常に定期的に更新する必要があります。問題は、セキュリティ修正と同時に新機能やその他の変更を取り込むかどうか（その場合はreleaseまたはlatestを使用）、またはそれらについては6ヶ月ごとのような間隔を好むか（その場合はesrを使用）です。
この新しいナンバリングスキームはまだ始まったばかりなので、新しいシステムに移行するにつれてドキュメントとツールは進化し続けます。
「いいね！」 3
前回2026.0にアップデートしたのは12月で、現在はv2026.2ですが、4月にはESRになるのですよね？
すべてのサポート情報については、releases.discourse.org のホームページをご覧ください。2026.1 は現在の延長サポートリリースであり、2026年10月までサポートされます。
2026.2 は2月中にリリースされ、その後2か月間セキュリティ修正を受け取ります。これは延長サポートリリースではありません。
「いいね！」 2
2026.1.0 は、iOS やその他の古いブラウザのサポートを終了する最初の安定版/ESR リリースですか? それはリリースノートのどこかに記載されるべき大きな変更です。しかし、最後にあった「詳細な変更点」の検索ボックスでは何も見つけられませんでした。
ああ、それは v2026.1.0-latest → v2026.1.0 の変更履歴へのリンクになっているからだと思います。それをv3.5.3 → v2026.1.0に変更すると、369件ではなく2397件の詳細な変更が表示されます。これらの ESR リリースでは、-latest ではなく、最後の ESR リリースへのリンクを設定すべきだと思います（あれは RC のようなものですか？）。
古いブラウザのサポート終了を明確に示した変更点はまだ見つけられませんが、少なくともこれを見つけることができました: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
「いいね！」 2
はい 
はい。ほとんどの人は Discourse の latest または release ストリームを使用しているため、変更履歴サイトはその点に最適化されています。ESR を選択するユーザーは、アップグレードのたびに実質的に「5 バージョンをスキップ」するため、それらの中間バージョンの変更点を確認する必要があります。
個々の中間変更履歴を閲覧するか、フィルターを使用して全範囲をカバーするカスタム変更履歴を生成する（あなたがやったように）ことができます。おそらく、リリースサイトのユーザーエクスペリエンスを改善し、ESR から ESR への比較に素早くジャンプできるようなリンクを追加できるかもしれません。
前回の「安定版」リリースを振り返ると、その時も「メガ変更履歴」はありませんでした。完全な変更点を把握するには、中間ベータ版の変更履歴をすべて読む必要がありました。ですから、UX はスムーズではありませんが、完全な変更履歴を確認できるようになったという点では、私たちは正しい方向に進んでいると思います。
とりあえず、OP にその ESR から ESR への比較へのリンクを追加しました。
フィードバックありがとうございます！
「いいね！」 3
特定のリリースから別のリリースへ、あるいは latest の任意の時点から最新の latest へと移行する際に、コミット x と y の間の変更が組み込みのアップデーターによって適用できず、代わりに新しいイメージからコンテナーを再構築する必要がある場合、新しいリリースノートシステムはそれを識別し、再構築の必要性について言及しますか？
別に、組み込みのアップデーターは更新をブロックし、再構築を促しますか？
組み込みのアップデーターに関する私の漠然とした理解では、Docker_manager を更新した後、再構築が必要な場合は Discourse の更新をブロックするということです。しかし、これを正式に確認したことはなく、体感としても完全には信頼できないように思えます。
具体的には、完了した Docker_manager の更新からバージョンページに移動したとき、Discourse の更新が開始可能になっていることがありますが、ページを更新した後にのみブロックされることがあります。[（これはかなり前に見たことで、おそらく修正されただろうと注記しておきます。）]
「いいね！」 1
再構築の必要性は、Discourseの「Dockerベースイメージ」に関連しており、これはDiscourseのバージョン番号とは完全に切り離されています。これは、Dockerイメージ内のOSレベルの依存関係に重要な変更があった場合に必要になります。
そのため、Discourseのコアリリースノートに含めるのは難しいでしょう。しかし、UIからアップデートできないことが驚きや不満につながることは理解しています。UIに関して改善できる点があるかもしれません。
「いいね！」 4
これは次のように機能することを想像できます。
- ホームページに「リリースチャネル」フィルターを設ける
- すべてのリリース
- 延長サポートリリース (ESR)
- ESRチャネルを表示している場合、それらのリリースのみがリストされ、リリースをクリックするとそれらの違いへのリンクが表示される
とはいえ、バージョン管理作業全体にとって現在より重要な、他の優先事項がまだいくつかあります（例えば、テーマコンポーネント/プラグインの互換性の問題など）。
「いいね！」 1
ああ、UIから常にアップデートできないことは問題ないと思います。Discourseをセルフホストしている個人や企業など、誰でも、ホストシステムを最新の状態に保ち、Discourseを再構築するなどのタスクを実行できる、少なくとも基本的なサーバー管理スキルを持つ担当者を配置する必要があります（すべきです）。
私の考えでは、最も重要なことは次のとおりです。
- 変更が（それなしでは壊れるほど）新しいDockerイメージでの再構築に依存している場合、UIからアップデートすることはできないはずです。
- 再構築が必要な場合は、それがわかるように表示されるべきです。
UIがDocker_managerを更新した後、常に正しく更新される限り、つまり、Docker_managerが最新であることを認識しているが、再構築が必要であることを認識していない状態にならない限り、これら2つはすでに真実だと思います。
「いいね！」 3