バージョン番号とリリースプロセスの見直しに関する進行中のプロジェクトの一環として、releases.discourse.orgを発表できることを嬉しく思います。
今後、このサイトがDiscourseのバージョン、リリース日、サポート期間、変更履歴に関する情報の主要な情報源となります。
ホームページには、最近のバージョンとその開発/サポート期間の視覚化が表示されます。その後、クリックして特定のバージョンの変更履歴を表示できます。例えば、最近の2025.12.0リリースです。
今後のリリースでは、Metaで専用の#release-notesトピックを作成する代わりに、これらのページへのリンクを掲載する予定です。
このサイトでは、任意のバージョン/コミット範囲のカスタム変更履歴を生成する機能もサポートしています。Discourse自体のアップグレードUIからこれらの変更履歴へのリンクを開始する予定です。
フィードバックがありましたらお知らせください！
releases.discourse.org の release-notes に現在含まれているプラグインのコミットはどこで見つけられますか？
小さな機能リクエストです。
「詳細な変更点 (Detailed Changes)」の下にリストされている個々の変更点 (commit-card) にアンカーリンクを追加していただけませんか？
これにより、特定の変更点を共有するのがずっと簡単になるはずです : )
コアプラグインの変更は他のコアの変更と一緒になっているため、欠けているのは「コアではない公式プラグイン」だけです。他のリポジトリからの変更を追加することは将来的に検討するかもしれませんが、現時点では実装の予定はありません。
コアではないプラグイン（公式およびサードパーティ）については、現時点では GitHub で変更を追跡するのが最善の方法でしょう。
良い考えですね！コミットリストは「仮想リスト」として実装されており、画面に表示されている要素のみが実際にレンダリングされるため、実装は少し難しいかもしれませんが…何ができるか見てみます。
それは残念です。discourse/discourseリポジトリにないプラグインの要約は、リリースノートで私が最も興味深いと感じた点でした。コアの変更はすべてGitHubで一か所で見つけることができます。しかし、他のプラグインの変更は異なるリポジトリで行われるため、すべてを簡単に追跡できる単一の場所がありません。
アクティブな開発とサポートのライフサイクルを視覚化するのに良さそうですね。
一つ気づいた点として、v2026.01 リリースには [latest] タグが付いていますが、v3.5 のように [ESR] タグが付いていません。両方あると一目でわかる参照情報として役立ちます。
バージョンに関するリリースとアクティブ開発の間の追加情報がある場合、Discourse を特定のリリースまたは ESR バージョンに固定するための設定（または追加する予定）はありますか？
これに関して注意すべきもう一つの点は、プラグインやテーマがDiscourseの異なるバージョンと互換性のあるブランチを作成するための自動化を構築するというRFCで計画があることです。
この件について再検討するのは、それが整った後だと思います。
これは現在、デプロイ設定で追跡するブランチを設定することで可能です。
しかし、そうすると、永遠にそのリリースに固定されてしまいます。私たちがまだ構築する必要があるのは、（フォローしているリリースのチャネルに関係なく）新しいリリースがいつ利用可能になるかを確認するためのより良い方法です。
これらがどのように機能するかについて初期の議論はありましたが、まだ詳細を議論中です。
これは素晴らしいですね。一目でどのバージョンを使用しているか、そして次のバージョンに移行する計画を立てる必要がある時期を素早く確認できるので、本当に役立ちます！このページの大ファンです 
セキュリティ修正と主要な機能が強調されているのが気に入っています！破壊的変更（breaking changes）も同様に強調されることを願っています。
また、ESR（延長サポートリリース）は、人々が両方が非アクティブな開発期間中であっても、あるESRから別のESRに切り替えることができるように、もう少しだけ（おそらく1〜2か月）サポートされるのが理想的だと提案します。そうしないと、コミュニティは、待ってサポート期間外になるか、早期に移行してサポート期間中にとどまるが、より多くの開発中のアップデートを受け入れるかのどちらかを選択する必要があります。わずかな重複があれば、ブランチがより安定する機会が得られます。これは、例えばMediaWikiなど、ESRのライフサイクルではかなり一般的です。
これは特に凝ったものである必要はなく、古いESRブランチに対する、あと1〜2か月の優先度の高いセキュリティ修正があれば十分です。
いずれにせよ、これは物事を非常に明確にするのに役立っています。^.^
はい、新しいリリースシステムでは、ESRサポートの2か月の重複を予定しています。したがって、2026.1は9月までサポートされ、これは2026.7 ESRがリリースされてから2か月後になります。
残念ながら、既存の「安定版」3.5には専用ブランチがないため、その重複を提供するのは容易ではありません。しかし、2026.1以降は、更新頻度を低くしたい人々にとって状況ははるかに良くなるはずです。
素晴らしいですね、ありがとうございます！
