# mvirt 0.5.0 migrations: yes wire: unchanged rev: 700ea1c261a1ff558267c443db8d200b3a204e5d mvirt 0.5.0 — the release train, and cluster formation Two things land together: a release is now a git tag and nothing else (ADR-0069), and a cluster forms itself instead of being assembled by hand (ADR-0071). The release train ----------------- - Tag-push is the only thing that publishes. A tagged run refuses a lightweight tag, a tag that is not an ancestor of main, a tag that disagrees with the workspace version, a tag whose message contradicts what the tree says, and a patch that migrates the store. `workflow_dispatch` builds and checks but cannot publish. - Every binary knows which release it is: `GET /v1/version`, the control plane's boot line, `mvirt-node --version`, and per-node versions with a skew flag on `GET /v1/nodes`. Until now the whole fleet reported `0.1.0` regardless of what was deployed. - `lib.mkFleet` in the deployment flake: one declaration per server feeds both the install path and the colmena hive. The documented upgrade command works for the first time — the shipped example had dropped the module arguments colmena needs, and no release check had ever evaluated it. - Backups are what make the rollback statement true. The control plane writes one immediately before it applies migrations, and daily after that, each paired with the envelope key a restore needs. The runbook now says plainly what a migrating release costs to undo. Cluster formation ----------------- The first server seeds the cluster and joins its own control plane with no step of yours; every server after it joins by redeeming a single-use token, either from a token file placed on the machine or with the one line the console generates. Upgrading to this release ------------------------- **It migrates the store.** Upgrade the control-plane host first, then each node one at a time. Once the control plane has started, the previous version will refuse to run against the migrated store — so rolling the control-plane host back means restoring the backup it took just before migrating, losing anything written since. Nodes roll back freely by booting the previous NixOS generation. ## Upgrading Point your flake's `mvirt` input at this release and redeploy the control-plane host first, then each node in turn: ``` nix run .#colmena -- apply boot --reboot --on nix run .#colmena -- apply boot --reboot --on # one at a time ``` **This release migrates the store.** Once the control plane has started, the previous version will refuse to run against it — migrations are forward-only, so rolling the control-plane host back means restoring a backup, with data loss back to the backup point. The control plane writes a backup immediately before it applies migrations; nodes roll back freely by booting the previous generation.