这份文档用于统一记录当前平台矩阵的升级原则、优先顺序和注意事项。目标不是“看到新版本就升”，而是保证这套平台长期稳定可维护。
当前这套平台已经覆盖了代码、监控、统计、文档、密码管理、自动化、内容与轻量工具等多个方向。
所以升级的原则应该是：
- 稳定优先，不是版本号优先
- 先备份，再升级
- 先测关键服务，再动非关键服务
- 敏感平台谨慎升级
- 大版本升级必须单独安排窗口
这些平台当前建议先稳定运行，不要为了“有新版本”就立刻升级：
- Umami
- Vaultwarden
- n8n
- Wiki.js
- FreshRSS
这些平台后续可以选窗口升级，但仍然不建议随手乱动：
这些平台后续升级成本相对最低：
- IT-Tools
- Excalidraw
- ShareBin（按需功能迭代，不是传统版本升级）
这些平台一旦出问题，恢复代价更高：
- 涉及密码和敏感数据
- 升级前必须备份
- 最好有回滚方案
- 当前已修复 PostgreSQL 查询兼容问题
- 不适合现在立刻做大版本跃迁
- 工作流和节点兼容性变化可能影响已有配置
- 当前也还在继续完善中
如果后续要分批做，我建议按这个顺序：
- IT-Tools
- Excalidraw
- Memos
- Uptime Kuma
- FreshRSS
- Wiki.js
- Gitea
- n8n
- Umami
- Vaultwarden
这个顺序的原则是：
- 先动轻量、无状态或弱状态的服务
- 再动中等重要服务
- 最后才动核心数据和敏感平台
每次升级前，建议至少确认这些：
- 当前服务是否稳定运行
- 是否已经完成备份
- 是否知道配置文件位置
- 是否知道数据目录位置
- 是否知道如何回滚
- 是否确认这是小版本还是大版本升级
- 是否确认升级说明里有没有 breaking changes
升级完成后，至少验证：
- 页面是否可访问
- 登录是否正常
- 核心功能是否可用
- 数据是否完整
- Nginx / systemd 是否正常
- Uptime Kuma 是否仍能监控到服务
- 当前页面里会提示 v3.0.3 可用
- 这是升级提醒，不是故障
- 现在建议 Dismiss，先不动
- 后续如需升级，必须单独做备份和验证
- 这是敏感平台
- 当前目标是稳定可用
- 后续升级一定要小心，不适合顺手处理
- 现在的重点不是升级，而是把工作流真正跑顺
- 升级优先级低于“把现有链路补完整”
- 不集中升级
- 先稳定运行
- 先把文档、备份、初始化收尾
- 先挑一个轻量平台练手升级
- 例如 IT-Tools 或 Memos
- 单独安排“核心平台升级窗口”
- 再处理 Gitea / Umami / Vaultwarden / n8n 这类重要平台
当前升级策略的核心一句话就是：
先稳住，再升级；先文档和备份，再版本迭代。
现在这套平台刚搭成型，最重要的是把它们变成长期资产，而不是一边搭一边频繁追新版本。