Poll: when a new DSH release ships, what is your install/upgrade strategy? (0.1.5 → 0.1.7 context)

[nanami-0713]

Context. The 0.1.5 → 0.1.7 window has been the roughest upgrade stretch so far: half-published tags (#7448, #7584), settings and presets dropped without migration (#7445/#7534/#7634, #7765), sessions refusing to load across versions (#7576/#7617), plugin updates deadlocked during release min-age (#7749/#7776/#7716), and user-layer files that can kill both boot and rollback (#7764). A community recovery checklist exists (#7654), and #7492 asks for a migration tool — this poll asks the complementary question:

When a new DSH release ships, what is your actual install/upgrade strategy?

Reply with a letter + your current version + what bit you (if anything):

• A — Ride every release. Update immediately (npx @deepseek-ai/dsh@latest or your package manager's latest). Breakage is the price of fresh fixes.
• B — Pin an exact version. Upgrade only after a release has baked for a few days/weeks. (Pinning as a habit: [Idea] Long-run reliability: version pinning, stuck-tool timeouts, and power assertions while sessions are active #6542; tooling: dsh-compat-guard: upgrade gate + compat matrix + lockfile/rollback for DSH's release chaos #4487, DSH｜DSH Safekeep｜让无人值守工作中的常见文件事故尽可能可恢复 #7333.)
• C — Skip the storms. Stay on a known-good version and skip specific bad releases until the canonical fix lands.
• D — Source install. pnpm / git on master; you choose the upgrade timing yourself (and own your pnpm run clean fails on a clean checkout: clean: expected TypeScript outDir to end in /types #7760).
• E — Something else. Describe it — including "I don't upgrade at all".

Why ask now: the release cadence is roughly one alpha/rc per day, and the failure mode has shifted from "won't start" to "starts, then quietly mangles state" — which changes the cost matrix between these strategies completely. I'll summarize results into #7492 (migration tool demand) and #6542 (pinning habit) as a demand signal.

---

背景. 0.1.5 → 0.1.7 是迄今最凶险的升级窗口:半发布的 tag(#7448/#7584)、设置与预设无迁移直接丢(#7445/#7534/#7634、#7765)、跨版本会话拒读(#7576/#7617)、插件在 release min-age 期间更新死锁(#7749/#7776/#7716)、用户层文件能把 boot 和回滚一起杀掉(#7764)。社区已有恢复清单(#7654),#7492 在求迁移工具;本投票问的是互补的问题:

新版 DSH 发布时,你实际的安装/升级策略是什么?

请回复字母 + 当前版本 + 有没有被咬到:

• A — 每版必跟:立即更新,坏版本当尝鲜的代价。
• B — 钉精确版本:等一个版本"焖熟"几天/几周再升(钉版本提案 [Idea] Long-run reliability: version pinning, stuck-tool timeouts, and power assertions while sessions are active #6542;工具 dsh-compat-guard: upgrade gate + compat matrix + lockfile/rollback for DSH's release chaos #4487/DSH｜DSH Safekeep｜让无人值守工作中的常见文件事故尽可能可恢复 #7333)。
• C — 跳过风暴版:停在已知好版本,坏版本直接跳过,等官方修复落地。
• D — 源码安装:pnpm / git 跟 master,升级节奏自己说了算(以及自己面对 pnpm run clean fails on a clean checkout: clean: expected TypeScript outDir to end in /types #7760)。
• E — 其他:欢迎描述——包括"从不升级"。

为什么现在问:发版节奏已到约每天一个 alpha/rc,失败形态从"起不来"变成"能起来但悄悄弄坏状态",各策略的成本结构完全变了。结果会汇总进 #7492(迁移工具需求)与 #6542(钉版本习惯)作为需求信号。

[xiaoyuyu6420]

Our strategy, for what it's worth as the backup plugin author who has been reading this window's incident reports closely:

Pin the running install; upgrade deliberately, never in-place on the live data. Concretely: let the dsh-pre-upgrade- snapshot land before anything else touches the install (the plugin does this automatically on host version change), run a read-only migration pre-check over all session logs first (/backup migrate-check — it enumerates which sessions the new migration chain will refuse and on which rule), and only then move. If the pre-check shows refusals, either fix them (session-surgeon handles most shapes) or accept losing access to those specific sessions before committing — the point is deciding before the upgrade, not discovering after.

For plugin updates specifically we added a one-shot /backup update that snapshots first and then walks the official plugin update, so a broken update is a rollback rather than a recovery project — written after watching #7749/#7776/#7716 style deadlocks.

The honest framing of this poll: the reason strategy matters more now is that the risk moved from "upgrade breaks the runtime" (reinstallable) to "upgrade changes what your old data means" (migration refusals, settings one-shot imports). Runtime breakage costs an evening; data-semantics breakage costs history. Optimize for the second class: snapshot before, pre-check the migration, keep a way back.

[nanami-0713]

Thanks — this is the most concrete option-B implementation in the thread. The line worth quoting back: "Runtime breakage costs an evening; data-semantics breakage costs history." That's exactly why this poll frames the failure mode as "starts, then quietly mangles state" rather than boot failures.

Two notes: (1) your snapshot → migrate-check → decide → move flow turns B from a habit into a procedure; I'll cite this comment as the reference implementation when I summarize into #7492/#6542. (2) If the backup plugin is public, drop the link here — people landing on B from this thread will want the tooling, and #7654's new step 4 (session-surgeon for the already-refused half) pairs with it naturally.

Counting this as B (with tooling) unless you correct me.

[FalseLeonLai]

D

[nanami-0713]

Logged — one vote for D (source install). If you feel like adding color later: has the daily alpha/rc cadence changed how often you actually pull master, and has the #7760-style pnpm run clean roughness bitten you? Every detail feeds the summary.

[njcray2]

C. 0.1.5-rc2.

I had to patch for the 300s timeout in Undici. Then npx stopped working for a while forcing me to do an install. Then I hit the problem with session v0 failing to load. (My local qwen3.8 resolved that one!)

My current plan is to stay on 0.1.5-rc2 for a considerable time. It works well and I am not in a hurry to pick up new, fairly small features. I would rather wait until something is added that I truly need or the Undici timeout bug is fixed upstream at least.

[nanami-0713]

That's textbook C — three different failure classes in one hop (the Undici family: the 300s timeout / content-encoding mangling #7468/#7502, npx breaking mid-window #7135, and a session refusing to load across versions), none of which any release's feature list justifies. "Stay until something I truly need lands or Undici is fixed upstream" is exactly the cost-benefit this poll is trying to surface — most quiet users never post, they just silently become C.

One data point for your wait: the Undici family keeps growing across versions (content-encoding #7468/#7502, reported as far back as 0.1.1-rc.2; proxy 3xx no-follow #7966/#7967 on rc.2), and no release notes so far claim a fix — so your condition may hold for a while. I'll fold your story into the #7492/#6542 summaries as the anchor case for C.