release: 0.6.4

docs/release-notes/0.6.4.md

@@ -0,0 +1,99 @@
+**Upgrading no longer destroys your configuration. If you have ever edited `appsettings.json`, this
+is the release to take.**
+
+## What was happening
+
+Installing from a release zip did not merely overwrite `appsettings.json` — it **deleted everything
+in `C:\Program Files\MultiSeat` first**, then copied the new build in. Every host-local setting went
+with it, nothing was backed up, and nothing said so.
+
+That included `appsettings.local.json`, the file the documentation recommends precisely because a
+deploy cannot overwrite it. True of a build from source; not true of the zip install, which is how
+almost everyone upgrades.
+
+The damage was quiet. On the machine where this was found, the dashboard API kept working purely by
+luck — the key falls back to a file under `ProgramData` that the deletion does not reach, so the API
+answered, just with a different key than the one that had been configured. Anything holding the old
+key would have started failing with no explanation. Settings without such a fallback were simply
+gone.
+
+## What happens now
+
+`appsettings.json` and `appsettings.local.json` are copied out before the install directory is
+cleared and copied back afterwards, **byte for byte**. Your `appsettings.json` wins over the one in
+the release — the shipped file is what a first install needs, not an upgrade.
+
+A timestamped copy of both is kept under `C:\ProgramData\MultiSeat\config-backups\`, outside the
+directory being cleared, so there is something to go back to even if the restore itself goes wrong.
+
+**Settings this release adds that your file does not have are listed during the install**, with a
+note that they will run at their built-in defaults. Keeping your file is right; hiding a new option
+from you is not.
+
+## This protects the upgrade you are about to do
+
+⚠️ **Correction.** The pull request that fixed this said the fix was "not retroactive" and would only
+protect the upgrade *after* the one carrying it. **That is wrong.** The installer that runs during
+an upgrade is the one inside the release you just downloaded, not the one already on the machine —
+the documented command runs `.\scripts\install-service.ps1` from the extracted folder. So upgrading
+from 0.6.3 to 0.6.4 uses 0.6.4's installer, and your configuration is preserved.
+
+The one case it does not cover is running an installer from an older extracted copy against this
+zip. Extract this release and run its own installer, as the instructions say, and you are fine.
+
+## Install
+
+```powershell
+.\prerequisites\install-prerequisites.ps1     # drivers - needed either way
+.\scripts\install-service.ps1 -FromZip .
+```
+
+Self-contained as always: no clone, no .NET SDK, no .NET runtime, no Node.
+
+After installing, confirm what actually landed:
+
+```powershell
+& 'C:\Program Files\MultiSeat\MultiSeat.Service.exe' --config
+```
+
+It should report `0.6.4`. A stale deploy looks identical from the outside, which is the whole reason
+that command exists.
+
+## Also in this release
+
+The documentation claimed in two places that a deploy could not overwrite `appsettings.local.json`.
+That was true of a source build and false of the zip install. Both now say what is actually true.
+
+## Verified
+
+The fix was tested against a real upgrade rather than in a harness: a live install with a
+deliberately edited `MaxSeats` and a deliberately removed setting, upgraded from the published
+`v0.6.3` asset.
+
+```
+before  appsettings.json       E7AC4C57508AF9BF  1579 bytes
+after   appsettings.json       E7AC4C57508AF9BF  1579 bytes
+before  appsettings.local.json 60CC6361B5C0EB1F    81 bytes
+after   appsettings.local.json 60CC6361B5C0EB1F    81 bytes
+```
+
+The edited value survived, and the removed setting was correctly reported as newly added by the
+release.
+
+## Unchanged from 0.6.3
+
+Everything else. This release contains no functional changes to seats, streaming or the API — only
+the installer and the documentation.
+
+## Known limitations
+
+Carried over from 0.6.3 and still true:
+
+- **Seats capture the RDP surface, not a dedicated virtual display.** A seat's display reports a
+  1000 Hz refresh rate, which is the sign of it. A Windows constraint on where a virtual display
+  can attach, not a regression.
+- **A streaming seat still reports its status as `Ready`.** The stream works; the status does not
+  reflect it.
+- Seat auto-discovery in MoonlightVibe did not find seats from another machine. Fixed in
+  MoonlightVibe, but not yet in a release of it — add the seat by address and port for now, where a
+  seat's port block starts at 48100 by default.

version.txt

@@ -1 +1 @@
-0.6.3
+0.6.4