# mvirt 0.7.0

migrations: yes
wire: unchanged
rev: 2347a2fea96e381a10abdf300785c8b0cef7ab2d

mvirt 0.7.0


The console now notices a release and offers to take it. 0.6.0 shipped the
machinery for that and could not use it: the release channel was an environment
variable nobody sets, so every install followed `stable`, whose pointer is
written by the announce step — and announcing requires the fleet to have run the
release first. The fleet that had to take a release in order to announce it
could therefore never see it. Production ran the whole feature and reported no
update available.

What changed:

- CI publishes a catalogue. `index/releases.json` lists every release that
  exists, rebuilt whole from the tags on each release and keeping only what the
  registry actually serves, so a tag whose run died cannot offer an operator an
  upgrade to a release nobody can fetch. This is the only way a cluster can
  learn which versions exist: the package listing API needs credentials and the
  source repository is private, so neither the registry index nor the Forgejo
  releases API answers an unauthenticated cluster.

- The release channel is a setting an admin picks in the panel, stored and
  surviving restarts, with the environment as the fallback.

- The update notice became an offer: it links into the upgrade flow, which leads
  with the one action that is safe fleet-wide — preparing builds the new system
  on every host and reboots nothing. Activation stays host by host, because that
  is where downtime lives.

Upgrade: control-plane host first, then nodes one at a time. This release
MIGRATES the store, so the control-plane host rolls back by restoring a backup,
not by booting the previous generation; the control plane writes one immediately
before applying the migrations.

## 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 <control-plane host>
nix run .#colmena -- apply boot --reboot --on <node>   # 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.