Upgrading

cargo install shep replaces the binary on disk and changes nothing that is already running. shep daemon reload is what moves a live flock onto it.

Replacing the binary

cargo install shep replaces the binary on disk. It does not touch anything already running: the shepherd keeps the code it booted with until you reload it, and each dog keeps its own until you reinstall it separately.

What carries across

A flock that can be carried keeps running through the reload. The shepherd replaces its own image in place, so every sheep keeps the pid it already had and its log carries on where it was. The dogs cross with it rather than being stopped and started alongside the flock; the dogs page says what each one does on the far side. One that cannot be carried is stopped and started instead, which moves every pid and starts every log again; the next section says which flocks those are.

If a dog cannot talk to the new shepherd, the reload names it. It waits for the dogs to reconnect first, so the answer is about the shepherd now running, not the one it replaced.

When it cannot carry

One thing still sends a reload down the older path: a sheep whose log pump has stopped answering. The shepherd cannot say which files that sheep is writing to, so it stops and starts the flock instead and names the sheep that held it back. Coming from 0.1.17 or earlier, the first reload always takes that path too: the shepherd being replaced predates the handover and has nothing to hand over with.

A reload re-reads the config too

The reload re-reads shep.toml too, and always has. So it is also the command for a changed log level, a new socket path or an edited [interpreters] table, with no new binary involved. It is a different verb from shep reload <sheep>, which replaces one sheep's processes and reads no file at all: the shepherd's own config and an app's Flockfile are two separate things that happen to share a word.

Version skew

shep start <Flockfile> used to be the one verb that did not refuse cleanly across that skew: applying a Flockfile to a running flock is additive, so the protocol number did not move for it, and the handshake passed while the shepherd then ended the connection on an envelope it could not read. It refuses cleanly now, because the --reset flag's own wire spelling changed and that is not additive the same way, so the protocol number moved with it. The number is 5 now: it moved twice more since, once for a set of live config-editing requests and once for a provider dog's own way to push into the secrets store, and both bumped even though the new requests were additive, for the same reason the rename did. Reloading first is still the whole fix either way.