[Feature] Discourse in the app store has not been updated for a long time

[KS-OTO]

1Panel Version

V2.2.5

Please describe your needs or suggestions for improvements

当前应用市场中的程序【 Discourse 】版本仅更新（截止）到 v3.5.0 （发布于2025年8月19日） , 但当前官方版本仍在持续迭代，并已更新版本到 v2026.9 （发布于2026年9月22日）
项目地址：https://github.com/discourse/discourse （47.7K stars ✨）
项目官网：https://www.discourse.org/open-source
项目版本发布主题页：https://releases.discourse.org
官方Docker镜像地址：https://hub.docker.com/r/discourse/base/

由于 Discourse 与25年9月，调整了版本命名规范，改为了“年月”命名版本号（如，v2026.6 ），并且开源社区也承诺每月均会发布版本，这就意味着 1panel 当下的版本跟踪规则会把 v3.5.0 ➡️ v2026.x 视为大版本跨版本升级，而放弃追踪，而后续每年自然年跨年时（ v2026.12 ➡️ v2027.1 ）也会视为跨版本升级而再次放弃追踪，为此**【 建议官方取消 Ddiscourse 的跨版本限制，始终保持应用为最新版本 】**；

Please describe the solution you suggest

No response

Additional Information

No response

[KS-OTO]

我检索了从语义版本（ v3.5.0 ）开始到现在最新的每一个版本（截止，v2026.9 ）的官方发布信息，有如下结论：

1. 从第一个日期版本（ v2025.11 ）的版本发布公告已确认：从v3.5.0 ➡️ v2025.11 完全可兼容性/无破坏性升级 https://meta.discourse.org/t/tests-passed-is-now-latest/384272
2. 官方与 v2026.1.8 作为长期支持的ESR版本（也是官方调整版本号策略后的第一个ESR版本），安全维护1年时间；
3. 从v2026.1 到最新的 v2026.9（预发行版本） 均无破坏性更新；

为此，基本确认可以直接跨版本升级；

但是，考虑到每个版本都有众多的新功能引入和修复，最保守/稳健的迭代升级路径应当为：
v3.5.0 ➡️ v2025.11.0 （第一个日期版本）➡️ v2026.1.0 （第一个ESR版本） ➡️ v2026.7.0 （第二个ESR版本） ➡️ 到最新的 Latest 版本（后续可平稳迭代升级）
理由如下：

• v3.5.0 ➡️ v2025.11.0 ：版本方案切换点，官方更新了容器配置文件的版本更新规则（ app.yml version tag ），重建后生效；
• v2025.11.0 ➡️ v2026.1.0 ：第一个官方ESR版本，这是为后续跨多版本升级做准备（官方有表达ESR版本可以顺利/兼容迁移到下一个ESR版本）；
• v2026.1.0 ➡️ v2026.7.0 ：第二个官方ESR版本，该版本包含过程版本（非ESR版本的月度版本）的若干累积性变更，包括存在部分废弃性和大功能引入（如：废弃.hbs主题格式，彻底移除 widget 渲染系统、PostgreSQL数据库版本提高到15（推荐PG18）、引入新的注册方式等等）；
• v2026.7.0 ➡️ Latest 版本：后续可持续保持最新版本升级；

扩展阅读：

• Discourse 官方调整版本维护的公告：https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536
• Discourse 官方表达可直接从上一个ESR升级到下一个ESR版本的文章：https://meta.discourse.org/t/jumping-from-2026-1-esr-to-2026-7-what-i-found/408779

[KS-OTO]

补充：由AI进行的三轮对照实测（验证升级可行性）

我让 AI 在测试环境（1Panel v2.2.5）完成了三轮对照实验，现将结论同步如下，供官方评估参考（ 以下内容均由AI生成 ）。

实验一：保持官方编排模板原文，仅将 image 替换为官方最新镜像 → ❌ 不可行

将 apps/discourse/3.5.0/docker-compose.yml 原文保留，仅把 image: bitnamilegacy/discourse:3.5.0 替换为 image: discourse/base:release-stable（官方每日构建镜像），结果：

vnumtest-discourse-sidekiq | Error: exec: "/opt/bitnami/scripts/discourse-sidekiq/run.sh": no such file or directory
vnumtest-discourse         | Restarting (0) 13 seconds ago   ← 立即退出进入重启循环，端口从未监听

原因在于官方新版镜像与 Bitnami 镜像是【 两套完全不同的运行时契约 】，仅修改版本号无法成立：

1. 入口/命令不兼容：模板中 sidekiq 服务硬编码的 /opt/bitnami/scripts/... 路径在官方镜像中不存在；web 服务依赖的 Bitnami 初始化逻辑（建库、生成 discourse.conf、创建管理员）同样缺失；
2. 环境变量契约不同：模板使用 Bitnami 风格的 DISCOURSE_DATABASE_* 变量，官方镜像使用 DISCOURSE_DB_* 并在每次启动时自动渲染配置文件；
3. 数据卷布局不同：Bitnami 卷挂载 /bitnami/discourse，官方体系为 /shared（uploads/backups/log 目录结构均不一致），旧实例数据无法被新镜像直接读取。

因此【 仅修改版本号 】的升级方式不成立，需要官方重构应用定义本身。

实验二：当前商店组合存在「全新安装即失败」的独立缺陷

• Discourse 3.5.0 的迁移脚本 20230710171141 EnablePgVectorExtension 强制执行 enable_extension(:vector)，而商店 PostgreSQL 应用为原生 postgres 镜像（不含 pgvector 扩展文件）→ db:migrate 必然失败；
• 实测 web 容器循环崩溃重启 215 次、应用端口从未监听、管理员账号从未创建；
• 换用同大写版本的 pgvector/pgvector:pg18 镜像后该问题即消失；此外冻结版镜像还缺少上游后期强制的 DISCOURSE_SECRET_KEY_BASE 注入逻辑，需手工补齐参数方可完成初始化。

实验三：基于官方镜像体系渐进式升级 → ✅ 成功且数据完整保留

以官方每日构建镜像为基础，复用面板的 PostgreSQL / Redis 应用执行跨版本升级：

• 数据库 schema 自 3.5.0 平滑推进至 20260810154331，数百条迁移零失败；
• 升级前创建的帖子与管理员账号在升级后完好可访问，站点 HTTP 200 正常对外服务。

对官方的建议

1. Discourse 应用定义改用官方镜像源 discourse/base:release-stable（官方每日构建、年月版本命名），并相应重写 docker-compose 与安装参数表单——这是商店能够持续跟进上游的前提；
2. 将该应用的 crossVersionUpdate 调整为 true（当前为 false，年月版本号每年自然跨号，均会被面板判定为跨版本更新而放弃跟踪）；
3. 在应用文档中标注对 PostgreSQL 的 pgvector 扩展依赖，或商店 PostgreSQL 镜像直接内置该扩展，避免"Discourse + 商店 PostgreSQL"组合全新安装即失败。

[wanghe-fit2cloud]

感谢反馈。

我们计划使用 discourse/discourse:2026.9.0-latest 重构应用定义，并适配新的环境变量、数据目录及 pgvector 依赖。

discourse/base 只是供 launcher 构建最终运行镜像的基础镜像，不能直接用于 Compose 启动，因此本次不采用。

新版本仅支持全新安装，不支持旧版本直接升级。