2026-05-21-14-35-20 合并Docker部署Release记录

工程分析/经验记录.md

@@ -1549,3 +1549,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 以后发布多部署形态时，不要只改 Release 文案；应使用不同 tag 固化不同文件状态。包含具体环境配置的版本可以保留当前内网、域名和 FRPC 信息；通用版本必须使用环境变量或占位模板，并在发布前全目录搜索确认没有遗留服务地址、token、远端端口和固定域名。创建 Gitea Release 后，应再通过 API 或页面确认 Release、tag 和目标提交一致。
+
+## 2026-05-21-14-35-20 多部署包应合并到单个 Release 的多个附件
+
+A. 具体问题
+
+用户指出机器直接部署版、NAS 直接部署版和通用版分别创建三个 Gitea Release 后，发布页面显得杂乱，查找和下载都不够直观；用户希望合并为一个发布项，并用不同附件名称区分部署场景。
+
+B. 产生问题原因
+
+此前把“部署场景”映射成了“Release 条目”，虽然 tag 追溯清晰，但 Gitea Releases 页面会出现多个同日期、同系统、只因部署配置不同而拆开的发布项。对使用者来说，版本概念应该只有一个，部署差异更适合作为同一 Release 下的资产附件呈现。
+
+C. 解决问题方案
+
+保留原三个部署 tag 和分支作为源码追溯锚点，新增整合 tag `revoxelseg-docker-all-v2026.05.21` 并创建单个整合 Release。使用 `git archive` 从三个 tag 分别生成本机直接部署版、威联通 NAS 直接部署版和通用版 `.tar.gz` 附件，上传到同一个 Release；确认三个附件均可从 Gitea API 读回后，再删除旧的三个分散 Release 记录。通用版发布前用文本搜索确认未包含固定 FRPC、域名和内网配置。
+
+D. 后续如何避免问题
+
+后续同一版本存在多个部署形态、系统架构或环境模板时，优先使用“一个 Release + 多个命名附件”的发布模型；只有当版本号、功能内容或源码状态确实不同，才拆成多个 Release。删除旧 Release 前必须先确认新 Release 的附件数量、名称和大小均已从 Gitea API 读回，避免页面清理造成发布物短暂缺失。