你好，
这里有一个我反复思考的想法：大多数关于“每次提交都有新版本可用”的挫败感，源于 latest 频道会持续更新。因此，落后几个提交实际上是 正常 的静止状态，但页面却将其视为异常。所以，与其重新设计整个系统，不如专注于区分信号与噪音。
我想象中的方案是，页面拥有一个状态横幅，其含义会根据你实际所处的状态而变化：
- 已是最新 → 安静、积极，无需采取任何操作。
- 落后
latest几个提交 → 灰色/信息性提示，并明确说明 无需操作。这是目前大喊大叫但实际上不应该的状态。 - 即将发布新的月度版本（例如
v2026.8.0）→ 醒目，并附带发布说明的链接。 - 安全更新 → 红色/紧急，单独标出。
只有最后两种状态才应让人感觉需要采取行动。
我还希望页面上包含以下其他内容：
- 版本号再次醒目地显示在中心位置。 只需一个小卡片，显示已安装的版本、提交哈希和频道（例如
v2026.8.0-latest.1 · dfe770d · latest）。这是我见过的最常见的抱怨，而且恢复它的成本很低。 - 利用我们已有的缓存检查。 版本检查已经作为定期 Sidekiq 作业运行，而不是针对每个请求实时运行，因此页面不应显得缓慢。它可以立即渲染缓存的结果，并显示一行“最后检查于 X 分钟前”以及一个手动“立即检查”按钮，而不是在加载时重新计算。
- 带有更新日志链接的更新历史 基本上就是本主题中的原始想法。一个简短的版本时间线（月度 + ESR），每个版本都链接到其更新日志或差异。
关于组件和重建： 我最希望明确区分的是 Web 更新器可以自行应用的更新（核心 + 插件，通过 git pull）和那些更改容器因此需要从命令行运行 ./launcher rebuild app 的更新。一个按组件列出的列表，每行显示其所属的类别，将大有帮助；对于需要重建的情况，它可以显示确切命令并附带复制按钮，而不是让你去猜测。
关于插件兼容性： .discourse-compatibility 机制已经处理了核心 早于 插件当前目标版本的情况，它会在重建期间静默检出该插件的最后一个兼容提交。这主要影响稳定/ESR 安装，且目前静默发生。如果能将其显示为一条纯信息性的“保持在兼容版本”提示，以便旧版本的管理员了解 为什么 插件没有处于最新提交状态，那就太好了。（相反的情况，即插件尚不支持 较新 的核心，目前并未真正处理；有一个关于最小/最大兼容版本的开放功能请求可以涵盖此问题。）
我快速制作了一个交互式原型，以查看不同状态并排时的感觉——老实说，最大的收获仅仅是“你落后了，但这没关系”这一状态。一旦它不再是一个警报，页面就会再次变得真正有用。如果有人想看看这个原型，我很乐意分享。