Feature request
Add an Updates page to the Windows OVMS Manager that lets users discover when a newer OVMS package is available and apply it through a safe, validated, recoverable upgrade — without manually locating release assets, unzipping, or editing environment variables.
This complements the standalone Windows installer/Manager (see #4347) and is implemented in PR #4350.
Motivation
On Windows, OVMS is distributed as a portable ovms.zip payload. Today, updating means: find the right release asset, download it, stop the server, unzip over the install, fix up environment/config, and restart — error-prone and easy to get into a half-upgraded, non-booting state. Because OVMS ships as a version-matched stack (ovms.exe + OpenVINO runtime + GenAI + tokenizers + Python), mixing individual DLLs across releases is a common failure mode. A guided, all-or-nothing upgrade flow removes that risk.
Components tracked
The Updates page reports installed vs. latest for the package as a matched set:
- Base package (the OVMS Windows payload / install marker version)
- OpenVINO Model Server (
ovms.exe --version)
- OpenVINO GenAI backend (bundled GenAI runtime version)
Versions are read from the local install (install.json marker + ovms.exe --version) and compared against release metadata for the matching package variant (python_on / python_off).
Expected behavior
Update check
- One "Check for updates" action checks all components together (they move as one matched package, not independently).
- Show, per component: installed version, latest compatible version, and a state —
Up to date / Update available / Cannot check (offline/metadata error).
- Only surface an Install/Upgrade action when a strictly newer, variant-compatible package exists.
- Provide release-notes links for Model Server and GenAI.
- Update checks are explicit/manual by default; periodic checks are opt-in (never auto-install).
Staged, validated upgrade (implemented in packaging/windows/scripts/upgrade-package.ps1)
- Stop the Manager-owned
ovms.exe (or the service, in service mode).
- Download the matching package to
%LOCALAPPDATA%\OVMS\packages.
- Verify the download (checksum/size) and that required files are present.
- Extract to a staging dir; run staged
ovms.exe --version as a smoke test.
- Back up the current install to
%LOCALAPPDATA%\OVMS\packages\backup\<version>.
- Replace the install files in-place; preserve user data under
%LOCALAPPDATA%\OVMS (settings, models, logs).
- Re-run configuration/marker update; restart the server if it was running.
- Run a health check; roll back from backup if version or health validation fails.
UI (Updates tab)
- A row per component (Base package / Model Server / GenAI) with installed version, latest version, status badge, and a release-notes link.
- A single "Check for updates" button and a contextual "Install update" button that appears only when an update is available.
- Progress and result surfaced inline (checking / downloading / verifying / upgrading / rolled back), with errors shown clearly.
- Never mixes DLLs from different releases — the package is the unit of upgrade.
Safety / non-goals
- No silent auto-install; user confirms before download and before applying.
- Version + variant must match the installed stack, or the action is blocked.
- User data (
%LOCALAPPDATA%\OVMS) is preserved across upgrades.
- Failed upgrades restore the previous working package from backup.
- Out of scope for the first version: delta/patch updates, background auto-update, and updating the Manager app itself (tracked separately).
Acceptance criteria
Value
Gives Windows Manager users a clear, guided, and reversible way to keep OVMS current, matching the local-desktop experience of tools like Ollama, while preserving OVMS's version-matched-stack guarantees.
Feature request
Add an Updates page to the Windows OVMS Manager that lets users discover when a newer OVMS package is available and apply it through a safe, validated, recoverable upgrade — without manually locating release assets, unzipping, or editing environment variables.
This complements the standalone Windows installer/Manager (see #4347) and is implemented in PR #4350.
Motivation
On Windows, OVMS is distributed as a portable
ovms.zippayload. Today, updating means: find the right release asset, download it, stop the server, unzip over the install, fix up environment/config, and restart — error-prone and easy to get into a half-upgraded, non-booting state. Because OVMS ships as a version-matched stack (ovms.exe + OpenVINO runtime + GenAI + tokenizers + Python), mixing individual DLLs across releases is a common failure mode. A guided, all-or-nothing upgrade flow removes that risk.Components tracked
The Updates page reports installed vs. latest for the package as a matched set:
ovms.exe --version)Versions are read from the local install (
install.jsonmarker +ovms.exe --version) and compared against release metadata for the matching package variant (python_on/python_off).Expected behavior
Update check
Up to date/Update available/Cannot check(offline/metadata error).Staged, validated upgrade (implemented in
packaging/windows/scripts/upgrade-package.ps1)ovms.exe(or the service, in service mode).%LOCALAPPDATA%\OVMS\packages.ovms.exe --versionas a smoke test.%LOCALAPPDATA%\OVMS\packages\backup\<version>.%LOCALAPPDATA%\OVMS(settings, models, logs).UI (Updates tab)
Safety / non-goals
%LOCALAPPDATA%\OVMS) is preserved across upgrades.Acceptance criteria
Value
Gives Windows Manager users a clear, guided, and reversible way to keep OVMS current, matching the local-desktop experience of tools like Ollama, while preserving OVMS's version-matched-stack guarantees.