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