从 v3.4.0 升级到 v2026.7.2 前需要了解的事项

支持 安装
1

我负责维护一个基于 Docker 的 Discourse 安装环境，运行在 Ubuntu 上，这是我作为一个开源项目的一部分而接手维护的。多年来，我一直通过 git pull && ./launcher rebuild app 进行升级，然后通过 /admin/update 处的管理界面完成更新。然而，在 2024 年 1 月，由于 docker_manager 导致的一次破坏性升级给我带来了痛苦的经历（参见此处提交中的评论，以及此处被回滚的提交），此后我便不再如此随意地执行升级了。

如今已经过去两年半了，我需要重新建立定期升级的节奏，但上次失败的升级仍让我有些紧张。我想请人帮忙理解的是，在尝试从 v3.4.0 升级到 v2026.7.2 之前，我应该了解哪些事项？我们的站点没有使用任何额外的插件，我唯一知道的特殊配置是我们使用 Discourse Connect URL 来实现与我们主社区站点的单点登录（SSO）。

过程是否就这么简单？

cd /var/discourse
git pull
./launcher rebuild app

然后通过管理界面进行更新？从 v3.4.0 升级到 v2026.7.2 时，是否有我需要注意的中间步骤？

谢谢，

Cory

2

或者……（如果你感到紧张）……先备份（无论如何都应该备份），然后搭建一个全新的服务器并恢复备份，完成后再将域名指向新服务器。

你会遇到的一个大问题是，有一个重大的 PostgreSQL 升级（升级到 18）。如果你搭建一个新服务器，就不必处理那个升级过程。

此外，还存在一个小风险，即你依赖的插件或主题组件可能没有得到维护，尤其是当它们由不太活跃的第三方编写时。

正是出于对风险的担忧，经验丰富的 Discourse 系统管理员（SA）会使用双容器配置，这样你可以在提交更新之前先引导（bootstrap）更新（尽管在遇到大型 PostgreSQL 更新时，这种方法帮助不大，但这种情况很少发生）

3

感谢您的回复。我很喜欢这个想法，会尝试一下这个方向！

4

我今天尝试进行迁移，结果又一次立刻遇到了 discourse_docker 主分支中的一个破坏性变更：

这个提交导致构建失败，并破坏了安装/设置过程，但它仍然被合并到了主分支中。这正是我担心的事情。

运行 ./launcher bootstrap app 后出现以下错误：

rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean?  assets:precompile

像这样的破坏性变更是如何被合并到作为官方安装说明一部分提供的主分支中的？构建失败被忽略了吗？我看到的错误就明确地出现在失败日志中：

Screenshot 2026-09-06 at 8.26.24 PM
Screenshot 2026-09-06 at 8.26.24 PM2096×926 217 KB

我能够检出之前的一个提交，从而让我继续执行迁移步骤，但这是连续第二次升级因未经验证的提交被合并到主分支而中断了。

5

嘿 @corywright，抱歉出了这个问题——当前的 ESR 中缺少该任务，补丁正在 这里 推进中。

我们会尽快修复，并且我会确保将 ESR 目标添加为冒烟测试目标，以防止未来再次出现此类回归问题。

6

再次感谢您建议采用此方案，而不是就地升级。这个方案效果要好得多，让我得以从一个全新的操作系统副本开始。