How updates work
Once the feed is live, whether SmartCom Revisited can update itself depends on how you
installed it. The app enforces this rather than guessing: the built-in updater will not
touch an install that a package manager owns, because replacing those files behind
dpkg's back is how you get an install neither of you can fix.
| Installed as | Updates itself? | What happens |
|---|---|---|
| Windows installer (NSIS) | Yes, in-app | Checks on start and downloads the update; you run the installer to finish, from the "Show the installer" button in the update panel. The build is unsigned, so SmartScreen warns when you do. |
| AppImage | Yes, in-app | Replaces the AppImage file in place. |
| .deb / .rpm | No | Your package manager owns these files. Download the new package and install it the same way you installed this one. |
| Windows portable | No | There is nothing to update in place — download the new .exe and replace the old one. |
| macOS | No | Not while the builds are unsigned — macOS refuses to replace an unsigned app in place. The app tells you a new version exists; download the .dmg and drag it over. |
What an upgrade keeps
All of it. Settings, saved connections, button sets, session logs and the audit log live in
your user data directory, not in the install, so replacing the application does not touch
them. That is as true of apt install over the top as it is of the in-app
updater.
Passwords and passphrases are in the operating system's own vault — DPAPI, Keychain or libsecret — and are not part of the install either.
On the AppImage specifically, settings live in
~/.config/smartcom-revisited — outside the AppImage file. No
update touches that directory, whichever tool performs the update, so replacing the
AppImage never costs you your connections.
AppImage update metadata
From 1.7.0 the AppImage carries standard update information and
a .zsync file is published alongside it. That is what AppImage update tools
read to work out which blocks of the file have changed. Earlier releases had neither, so
the AppImage was invisible to anything but the app's own updater.
Verified so far: the metadata is correct, the .zsync is well formed, and
the AppImage still runs. Not verified: that any particular third-party
AppImage manager works with it. That is a claim about someone else's program
and it needs two published releases to test properly — install one, publish the next,
watch the manager notice and update in place. Until that has happened this page will
not tell you it works.
Versions in the wild
1.7.0 is current. 1.7.0 and 1.6.1 and 1.6.0 and 1.5.0 and 1.4.0 and 1.3.0 and 1.2.0 and 1.1.0 and 1.0.0 still work; they are old rather than unsupported.
1.1.0 and 1.0.0 cannot do global variables, which arrived in 1.2.0 — that is why the exchange labels any set expecting one. On those builds an undeclared placeholder is sent to the device literally rather than being filled in.
Where the files come from
Every installer on the download page is served by this site, with the SHA-256 printed beside it. Because the builds are unsigned, that checksum is the only integrity check you have, so it is worth running — the commands for it are on the same page.
Checking what you have
The version is in the About dialog. If you are not sure which kind of install you have:
on Windows, a portable build is a single .exe you double-click from wherever
you left it, and an installed one has a Start menu entry. On Linux,
dpkg -l | grep -i smartcom or rpm -q answers it; if neither
finds anything, you are running the AppImage.
The download page has the current files, their sizes and their SHA-256 checksums.