v0.27.0 Migration Guide

Daemon hosting moves to installed binariesSection anchor link

The installed Sparkwing distribution now owns daemon lifecycle. Pipeline binaries keep the wire client and use a running daemon, but they never host, replace, or upgrade one. The sparkwing CLI starts (or upgrades) the daemon before executing a pipeline, and points the pipeline binary at itself through SPARKWING_WINGD_BIN; sparkwing-runner keeps hosting its own daemon.

Nothing changes on a host with the sparkwing CLI installed and on PATH, which is the normal laptop and CI setup. Upgrade the CLI to v0.27.0 or newer on any host that runs pipeline binaries built against this SDK: no release through v0.26.0 can host a daemon for such a binary, because none of them serves wingd supervise. A host whose installed CLI predates v0.27.0 refuses to host, and the error names the release to install. Pipeline binaries built against an older SDK are unaffected either way - they keep their existing self-hosting behavior and share a newer CLI-hosted daemon exactly as before, so a mixed box during a rollout is fine.

On a host with no sparkwing installed at all, behavior now splits by what the pipeline declares:

  • A pipeline that only uses implicit default reservations runs without coordination and prints one warning. Box- and run-scoped .Concurrency() groups keep working - they are enforced through the shared store, not the daemon - with weaker crash cleanup (a killed run's slot waits for sparkwing doctor).
  • A pipeline that pins host capacity with a plan- or node-level .Resources() reservation refuses to run, because CPU and memory have no fallback arbiter. Install the CLI, or set SPARKWING_ALLOW_UNADMITTED=1 (exactly 1) to force the uncoordinated path.
  • A daemon that is running but speaks an older protocol than the pipeline binary fails every run, pinned or not: it is holding capacity for other work, and joining it unadmitted would oversubscribe the box. The error names both versions and the minimum release; the same escape hatch applies.

sparkwing.ToolSlot on a daemonless host returns its documented granted=false fallback instead of self-hosting a daemon and being granted the budget. Job bodies already handle that return.

--sw-dry-run and other non-executing invocations (--explain, --plan, config) are exempt from all of the above.