こんにちは。
私が何度も思い浮かべるアイデアは、以下の通りです。「コミットごとに新しいバージョンが利用可能」という表示による不満の大部分は、latest チャンネルが継続的に更新されるため、実際には数コミット遅れていることが通常の待機状態であるにも関わらず、ページが何らかの異常があるかのように扱っていることに起因します。したがって、システム全体を再設計するのではなく、信号とノイズを区別できるようにすることに焦点を当てるべきです。
私がイメージしているのは、ページに1つのステータスバナーがあり、その意味が実際の状況に応じて変化するものです。
- 最新状態 → 静かで肯定的、アクションの呼びかけなし。
latestより数コミット遅れている → グレー/情報提供用、アクションは不要 と明示。これが現在警告のように表示されている状態ですが、本来そうあるべきではありません。- 新しい月次リリースが近づいている (例:
v2026.8.0) → 目立つ表示、リリースノートへのリンク付き。 - セキュリティアップデート → 赤/緊急、個別に強調表示。
後者の2つの場合のみ、アクションが必要であると感じさせるべきです。
その他、ページに含めたい要素:
- バージョン番号を再び目立つ位置に配置。 インストールされているバージョン、コミットハッシュ、チャンネル (例:
v2026.8.0-latest.1 · dfe770d · latest) を示す小さなカード。これは私が目にした最も一般的な不満点であり、復活させるコストは低いです。 - 既存のキャッシュ済みチェックを活用。 バージョンチェックは、リクエストごとにリアルタイムで実行されるのではなく、Sidekiqジョブとして定期的に実行されています。したがって、ページは低速感を避け、キャッシュされた結果を「X分前に最終チェック」という行と手動の「今すぐチェック」ボタン付きで即座にレンダリングし、ロード時に再計算しているように見せるべきではありません。
- 変更ログリンク付きのアップデート履歴 つまり、このトピックの元のアイデア。リリースの短いタイムライン (月次 + ESR) で、それぞれが変更ログまたは差分へのリンクを持つもの。
コンポーネントと再構築について: 最も明確に示したいのは、ウェブアップデータが自身で適用できるアップデート (git pull を通じたコア + プラグイン) と、コンテナを変更し、そのためコマンドラインから ./launcher rebuild app を必要とするアップデートとの区別です。各行がどのカテゴリに属するかを示すコンポーネントごとのリストは非常に役立ち、再構築が必要な場合は推測させるのではなく、コピーボタン付きの正確なコマンドを表示できます。
プラグインの互換性について: .discourse-compatibility メカニズムは、すでにコアがプラグインが現在ターゲットとしているものより古い場合を処理しており、再構築中にそのプラグインの最後の互換性のあるコミットを静かにチェックアウトします。これは主に安定版/ESRインストールに影響し、現在では静かに発生しています。これを「互換性のあるバージョンで保持」という単純な情報行として表示し、古いリリースの管理者がプラグインが最新コミットでない理由を見られるようにすると良いでしょう。(逆の場合、つまりプラグインが新しいコアをまだサポートしていない場合、現在では本当に処理されていません。最小/最大互換性バージョンに関するオープンな機能リクエストがあり、それがこれをカバーします。)
異なる状態が並んでどのように見えるかを確認するために、クイックなインタラクティブなモックをまとめました。正直なところ、最大の利点は「遅れているが問題ない」という状態です。それが警告でなくなれば、ページは本当に有用になります。誰かが触ってみたい場合は、モックを共有できます。