Version compatibility

Each repository carries its own semantic version and cuts its own GitHub Release; a control-plane release names the daemon and UI versions it was tested against. Both wires carry versions and enforce a floor, so a mismatch is refused with a message rather than discovered as a broken deploy.

Channels

Channel	What it points at	Where
`release`	The latest promoted release	`releases/latest/download/manifest.json` on each repository
`rc`	The current release candidate — a rolling pre-release tag	`releases/download/rc/manifest.json`
`trunk`	Every merge to `trunk` — contributors only, never production	`dl.trbp.nl/channels/trunk/manifest.json`

The daemon's built-in channel table and the control plane's are the same table; rc and release come from GitHub Releases directly (redirects, no API calls). Promotion is a pointer move — the bytes that soaked on rc are the bytes release serves.

Tested pairings

Control plane	Daemon	UI	Notes
0.1.0	0.1.0	0.1.0	First release. Every 0.1.0 build understands `managed.ingress.reconcile`, the `dockerNetworkAddressing[]` deploy field and the `GET /host/docker-networking` pull.

Version floors

Side	Floor	What happens below it
Control plane → daemon	`0.1.0`	The daemon reports its version on `hello`. A supported daemon runs commands; an unsupported one keeps its connection but every command fails with `daemon_unsupported` until it updates. A daemon that reports no version (pre-0.1.0 builds) passes as unknown.
App → instance	`0.1.0`	The instance stamps `x-turbopanel-version` on every response and the app sends `x-turbopanel-client-version`. The native app refuses to connect to an older instance and says which version it needs; an instance that sends no header is accepted. The bundled web UI always matches its instance.

Rule of thumb: upgrade the control plane first, then roll daemons fleet-wide. Mixing channels (a trunk control plane with release daemons, or the reverse) is unsupported outside active development.

Check versions

Surface	How
Daemon	`turbopaneld --version` → `turbopaneld v0.1.0 <commit> (…)`
Control plane (self-hosted)	`GET /api/health` → `version` and `revision.commit` (the release job stamps the exact commit)
Control plane (TurboPanel High Availability)	`GET /api/health` on the hosted origin, or the `x-turbopanel-version` response header
UI	The About screen; the web export ships as `turbopanel-ui-<version>.tar.gz` and reports itself in `x-turbopanel-client-version`
Server page	The daemon panel shows the running version and commit and names the channel target by version

Breaking changes

Breaking API or enrollment changes are called out in:

Changelog
GitHub Releases for turbopanel, turbopaneld and ui