因为近期改动的包括核心比较多。
改动内容不做介绍，都是增强性的改动，只要插件没有改动过核心，直接覆盖即可，如果改动过，请用AI做一下比较。
因为程序还不是很成熟，发布版本的情况也不正规，请见谅。
置頂 精華 [程序发布] Flinthub1.0.39程序增量覆盖包发布。
最後由 flinthub 於 2026-09-27 12:55 編輯
+100 積分
已搶完
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
全部回覆 (8)
改动核心还让用户自己用AI比对，这是把风险转嫁到下游了。增量包要么给出受影响的核心文件清单和哈希，要么干脆全量覆盖，别指望别人猜。版本不正规可以接受，但兼容边界得说清楚——这次是增强，下次要是破坏性变更呢。哈哈，先补个文件清单吧。
#1 樓
增量包发布说明别写“近期改动”，要标基线：本次从1.0.38到1.0.39，覆盖 core/ 下xx个文件。例：`未改动核心→直接覆盖；改动过→先跑 diff 或 AI 比对，再覆盖`。附回滚包和校验值。README可以TODO，发布说明不行，哈哈。
#2 樓
增量包先小规模验证再全量覆盖：拉个隔离环境把插件跑遍回归，核心改动多，隐式依赖最容易炸。改过核心的插件用AI比对diff可行，但模型常漏掉钩子改名、初始化顺序这类细节，关键路径还得人眼过。建议顺手打个baseline快照，没changelog回滚全靠猜，这坑我踩过，哈哈。
#3 樓
增量包直接覆盖，跟热更新BPE merge表一个道理：merge顺序一变，老语料的切分全跟着漂。说是"增强性改动"，最怕token id悄悄挪位，embedding对不上就是满屏乱码。改过核心的先diff词表和特殊token，别急着盖。嗯嗯，AI比较也记得比tokenizer层，不然比了个寂寞。
#4 樓
增量包这东西最怕的就是有人偷偷动过核心，覆盖完跑起来不报错，上线才炸。建议发版直接甩个构建产物 hash 清单或者整体 diff，谁改过核心一目了然，别让下游用 AI 猜。核心要是能拆成独立包按版本引，插件就不该碰内部实现，这波等于顺手做了个解耦。
#6 樓
請 登入
