# Tasks: Daemon Updates

Tasks by their numbers in the project-wide sequence, which continues across every spec. Built
and checked in one piece, so not broken into phases.

- [x] T253 Say when the daemon is another build than the window, and update it when the user asks, per FR-B01 to FR-B07, SC-B01, SC-B02 (R-108) — done: `midi_harbor_core::BUILD_ID` from `crates/core/build.rs`, one per package run through `MIDI_HARBOR_BUILD_ID` in `packaging/macos/build.sh`, the Makefile and `.goreleaser.yaml`; `ServerInfo.build_id` (7), protocol 1.3; the window shows a notice above every page with Update now and Not now and restarts nothing by itself; `ServiceManager::replace` stops, registers and starts, and `service install --start` uses it; `service status` says when the daemon is another build, `same_build` in `--json`; the App Store app stops a daemon another build left and starts its own. Tests: what the notice says and when it offers the button, as a table; the daemon reporting its build over a real socket; and the service lifecycle test now installs with `--start` over a running daemon and checks the process changed, with the stand-in service managers ignoring a start when running as the real ones do. Checked live on Arch Linux under systemd with two builds given different identifiers: build B's `service status` said the daemon was another build; its window showed "The daemon is a different build" with Update now; clicking it rewrote `ExecStart` to build B's path and the journal showed the daemon stopped and started 0.5 s apart, after which `same_build` was true and the notice was gone; build A's window opened beside it showed the notice and the daemon kept its start time. Not run: launchd, Task Scheduler and the App Store app's replacement, and the release build with the new environment variable. The view shown while the daemon restarts was not seen, the restart being over before the first screenshot.