Major update strands third-party plugins: no batch update path, minimumReleaseAge silently blocks same-day adapter versions

[wzn16]

Environment

• macOS 15 arm64, desktop 0.1.7-rc.2 → 0.2.0-rc.1 (installed manually after the in-app update failed, see separate issue)
• Profile: ~/.dsh/profiles/desktop, 22 third-party bundles

What happened

1. After the 0.2.0-rc.1 install, 11 third-party plugins were flagged 异常 (abnormal) — their peerDependencies
   only declare 0.1.x ranges, and the 0.2.0 host refuses to load them. None of the adapters had been updated
   automatically; the Settings UI offers enable/disable toggles but no "update plugins" affordance, and the
   desktop profile is not manageable via the dsh plugin CLI, so the only path was hand-running the bundled pnpm.
2. Updating via the bundled pnpm to the adapter versions published the same day was silently blocked by
   minimumReleaseAge (24h): pnpm update <pkgs> was a no-op (downloaded 0, added 0) with no hint why, and
   lockfile verification failed with ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION for entries already in the lockfile.
   I had to pass --config.minimum-release-age=0 to get the update through.
3. dsh-market's own update flow apparently appends that same flag to pnpm, and the desktop host's installer
   rejects it — from the market log:
   update dsh-context → 0.59.2 exit=1 … 这台宿主（官方桌面端）自己执行安装，不接受市场附加的 pnpm 参数（--config.minimum-release-age=0）

Net effect: on the day a major version ships — precisely when adapter versions get published — users cannot
install them through any first-party path, and nothing explains why.

Suggestions

1. On a host major/minor update, re-resolve the plugin tree and offer a one-click "update incompatible plugins"
   action in Settings (the marketplace already knows which installed packages fail the host's peer check).
2. When an explicit user-initiated update targets specific packages, bypass or prompt on minimumReleaseAge
   instead of silently skipping; at minimum log why a version was filtered.
3. Consider excluding "adapter release for the running host version" from the age policy, or auto-relaxing it the
   way the shell already auto-appends minimumReleaseAgeExclude entries for its own packages.

[bobcyw]

Sharing our breakage list from a different upgrade path (0.1.6-alpha.1 → 0.1.7-rc.1 → 0.1.7-rc.2), in case it helps whoever designs the migration path. We run a local customisation set — about 159 files changed vs upstream, plus several in-house plugins.

0.1.6

• Default protocol switched to Messages (upstream b0641b83fc). Non-text/image blocks in user/tool-result now throw UNSUPPORTED_CONTENT. 84 of our sessions stopped working — they carried reasoning blocks written by earlier subagent-settled notifications, which chat-completions used to ignore silently.
• session-persistence-jsonl: listArtifacts skipped truncated logs only for generation-0, so a single interrupted log made the whole plugin tree fail to load (server up, session list empty).
• session-log-deepseek: no size cap on injected events. A session at watermark -1 injected 152 MB in one request, got EPIPE, and never advanced the watermark — so every retry resent the same payload.
• token-meter: CHARS_PER_TOKEN = 4 underestimates Chinese by roughly 4x, so an 800K compaction threshold really fires around 2M tokens.

0.1.7

• The shared kind: 'plugin' was removed. session-peers and session-channels both needed PluginMessageSource + MessageSourceMap module augmentation.
• SummarizationInput / SummaryResult are no longer exported from the compaction-basic root.
• Type-level changes made 6 of our packages' .spec.ts incompatible; we had to move those test files out of the workspace.
• dsh-better-workspace depends on a settingsScope service that is not available in 0.1.7, so the plugin had to be disabled.

Longer version with sources: #8096.

Your 0.2.0 case (peerDependencies pinned to 0.1.x → 11 bundles flagged) looks like the same pattern one major version later. The two structural causes we kept running into were: (1) a plugin has no way to declare a host-version range that the host actually honours, and (2) the persisted message-source union has no extension point, so adding a member forces a session-format bump.

[Bruce-Yii]

Adding one code-level data point to this thread, from a fresh install on Windows + the official 0.2.0-rc.1 desktop build (no prior plugin state, single plugin). The gate itself gives the user no way to learn which version would work.

What the gate returns

evaluatePluginCompatibility() in packages/boot/app-boot/src/plugin-compatibility.ts returns:

interface PluginCompatibility {
  name: string
  version: string
  runtimeVersion: string
  peers: Record<string, string>   // only the *unsatisfied* requirements
  exempted: boolean
}

There is no field carrying "a published version that satisfies these peers". pluginCompatibilityWarning() therefore renders only:

Update the plugin or install a plugin version compatible with this dsh runtime.
To accept this risk explicitly, grant the exact-version exemption for <pkg>@<ver> on dsh <runtime> with dsh plugin allow-version or the plugin manager, then retry…

That is a dead end: the two instructions are pick a version (which one?) and accept crash/data-loss risk. Nothing in the result lets the agent answer the first one.

Concrete case

dshmarket declares, in peerDependencies:

version	@deepseek-ai/dsh-settings range	ok on 0.2.0-rc.1
1.66.3 (2026-09-27 16:30Z)	^0.1.0-rc.7 || ^0.1.1-rc.2 || ^0.1.2-alpha.2	no
1.66.4 (2026-09-28 14:29Z)	the above || ^0.2.0-rc.1	yes
1.66.5 (2026-09-28 15:06Z)	the above || ^0.2.0-rc.1	yes

Installing the bare spec dshmarket on 0.2.0-rc.1 was rejected against 1.66.3. dshmarket@1.66.5 installs cleanly. So a compatible version existed at the moment of the block — about 25 hours old — and the message had no way to say so. The only recovery was to diff npm metadata by hand and find that 1.66.4 is the first version adding || ^0.2.0-rc.1.

Two questions

1. Why did the bare spec resolve to 1.66.3? dshmarket's dist-tags.latest is 1.66.5. I enumerated the desktop's app.asar (13,026 files): there is no bundled plugin catalog/registry/market data file — zero non-node_modules .json whose name contains "plugin", and the top two levels are only 20 Electron-scaffolding files. So a pnpm resolution should land on latest. If stale registry metadata in the bundled pnpm store is responsible, the failure would be non-deterministic across installs, which matters independently of the UX gap. I have not confirmed this — I only know the resolved version was not latest.

2. Can the result carry a satisfying version? Independent of (1), adding the highest published version that satisfies peers — a suggestedVersion field, or appending it in pluginCompatibilityWarning() — would hand the agent one concrete line to read back. Cheaper than suggestion 1 above, and unlike that one it also covers the fresh-install path, where there is nothing to "update" because nothing was installed before.

[f-infinite-z]

Adding one more data point from the minimumReleaseAge path — we reproduced a related failure mode on Windows (desktop 0.2.0-rc.2) that may explain part of the "silently blocked" behavior.

What we observed (reproducible, bundled pnpm 11.7.0):

• When a fresh package (<24h) is installed directly, pnpm auto-appends a minimumReleaseAgeExclude entry in the form name@version to the profile's pnpm-workspace.yaml — so the direct install itself succeeds.
• The lockfile verification that runs on later operations still flagged those entries in our case. What broke it: once the same package name had two name@version exclude entries (an old version's entry plus a new one), the exemption stopped applying to the lockfile check and every subsequent install in that profile failed with ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION — even for unrelated, old packages.
• Working through variants on a copy of the profile: keeping only the newest name@version entry → passes; using bare package names (no version) in the exclude list → passes and keeps working across versions; minimumReleaseAge: 0 → passes.

So for anyone hand-editing around this: bare-name excludes seem more durable than per-version entries (which can accumulate and then stop being honored). Not claiming this is the exact path in the report above — just the mode we could reproduce, in case it helps the policy-side discussion.

Also seconding Bruce-Yii's suggestedVersion idea — having the refusal name a version whose peers satisfy the runtime would have removed the manual npm-metadata diffing in that dshmarket case.