关于发版节奏：建议攒一攒再发，而不是每个小修都发一个版本

[heptaspirit]

从 v0.7.10 到 v0.7.31，大概 3.5 天里发了 21 个版本，其中 9 月 8 日一天就发了 10 个。

我看了下发版流程：release-prep 是手动触发的（要人输入版本号再开 PR），所以这不是 CI 太激进，是有意为之。动机我也理解——修好了想让用户尽快拿到。

但这么发有几个实际代价：

1. 版本号不带信息了。0.7.28 到 0.7.29 可能只是改个错别字，也可能动了检索权重。用户没法从版本号判断要不要升。
2. 出问题不好回溯。一天十个版本，很难说清"我用的那个好版本"是哪一个。
3. release notes 变成流水账，重要的那条容易被淹掉。

几个做法，选哪个都比现在强：

• 固定节奏：两三天发一个版本，期间合并的改动都装进去。
• 按内容批量：攒够一个大功能，或者攒够几个同类修复，再发一版。
• 双轨：影响使用的 bug 立刻发，其余攒批。

顺便说个正在做的例子：scope 隔离（#17）是个大功能，我们打算整块做完、随 v0.8.0 一起发，而不是拆成十几个 0.7.x 补丁。

如果你有别的考虑（比如高频发版是为了某个具体目的），说来我们可以进一步讨论。

[modusensus]

感谢这份扎心的数据——3.5 天 21 版、9/8 一天 10 版，我回头看也承认这个节奏偏快了。

先讲讲为什么这么发，再讲打算怎么改。

为什么高频： dsh-mneme 现在社区里有一批在 0.7.x 上真实使用并做验收测试的用户（#57 macOS 验收、#89 重启连发样本、#118 向量卡报告，都是同一批深度用户）。他们报的问题往往在「正在用的版本」里就能复现，我们修完只想让他们尽快拿到。插件小、单次发布成本低（npm + release-prep 自动开 PR），主观上就没太克制。

但你说的三个代价全部成立，尤其第 1 条——版本号不带信息，0.7.28→0.7.29 到底动了什么用户无从判断，这是最伤的。

打算改成双轨（采纳你的第三种）：

• 立即发：影响实际使用的 bug（数据丢失、功能不可用、现有用户升级后出错这类）。
• 攒批发：内部重构、docs、CI、体验打磨、非紧急优化——攒够一批内容量再发，节奏固定 2-3 天。

这样版本差异应该一眼能看懂：hotfix 版只带修复，batch 版带「一批」有名字的东西。

scope 隔离（#17）：同意你的做法，整块做完随 v0.8.0 一起发，不拆 0.7.x 补丁。那批东西拆碎反而难 review、难回滚。

谢谢这帖，节奏确实该收敛了，从下一版开始按双轨走。