Yesterday we shipped v7.0.0 and called it the release where the app finally reads as one product. For desktop users on Windows, macOS and Linux it read as nothing at all: the installer ran fine, the icon appeared, and a double-click started a process that ended itself about two seconds later. No window, no message, no crash report. This page is the honest write-up of what went wrong and what v7.0.1 does about it.
What landed
The desktop app launches again
The shell registered an auto-update plugin that had no configuration to read, so initialization failed before the first window could open. The plugin is removed, update checks never used it anyway, and all seven installers are rebuilt.
Startup failures show a dialog now
If the shell ever fails before its window appears, you get a native error dialog with the actual error and the path to the launcher log. A process that exits without a word is no longer a possible outcome.
Stricter backend attach
The shell attaches to an already-running backend only when it reports a healthy status and exactly the same version. Anything else, a stale install, a foreign service on a busy port, gets logged and skipped, and the app boots its own backend instead.
A sturdier installer
The Windows installer now embeds the WebView2 bootstrapper instead of downloading it mid-install, and the bundled backend is built from a locked dependency set, so every build of the same version resolves identical packages on every platform.
What happened
The desktop app is a thin native window around the same backend that powers the web version. During startup in v7.0.0 that shell registered an auto-update plugin, but the build configuration carried no settings for it. The shell treated the missing configuration as a fatal initialization error and gave up before drawing a window, before writing more than three lines of log, and before telling anyone anything. The bitter part: the plugin was dead weight. Update checks ask GitHub for the latest release and point you at the download page, so removing the plugin cost nothing except the bug.
We reproduced the failure the honest way, on a clean Windows machine with the published 7.0.0 installer from the release page, the same double-click and the same nothing our users saw. The fix was verified the same way, with the published 7.0.1 artifact rather than a developer build: install, launch, window up, log clean.
Hardening that rides along
A silent death gave us a reason to make the whole startup path defensive. If the shell ever fails that early again, whatever the cause, a native dialog now reports the error and the location of the launcher log. The logic that lets the desktop app reuse an already-running backend used to accept any process that answered on a known port; it now requires a healthy status report and an exact version match, and writes down why it rejected anything it rejected. The Windows installer embeds the WebView2 runtime instead of fetching it during installation, which removes a network dependency from the one moment you least want one. And the backend that ships inside the installers is now built from a locked, platform-universal dependency set, so the artifact we test is byte-for-byte the artifact you download. The v7.0.0 release notes carry a warning that points desktop users here.
Upgrade
Desktop: download the new installer from the download page or from GitHub releases and run it over the existing install. Your data is kept; it lives in your user profile and the installer does not touch it. Server and web installs upgrade as always:
pip install --upgrade openconstructionerp
Docker users pull ghcr.io/datadrivenconstruction/openconstructionerp:7.0.1
or latest. There are no schema changes in this release and
nothing about an external DATABASE_URL connection changes.
Questions or trouble upgrading, write to
info@datadrivenconstruction.io.
Get v7.0.1.
Download the desktop app, run the live demo, or self-host in five minutes. AGPL-3.0, no signup required.