Conversation
On a copy of ZenNotes installed from the AUR, or unpacked from the
tarball, Check for Updates never came back. The About page showed
"Checking GitHub releases for updates…" and stayed there, and the check
that runs after launch never noticed a release either. unyanda reported
it on Discord ("mine never does"), and it has been true for every AUR
and tarball install since the updater shipped.
Those installs were being handed to the AppImage updater: since 2.40.0
by linuxUpdaterFormat on purpose, before that by electron-updater's own
default. That updater refuses to run without an APPIMAGE marker, and it
refuses silently: checkForUpdates() resolves null with no event. The
app had already set its state to "checking" and only ever left that
state on an event, so it never did.
A non-system, non-AppImage install is now its own case, "managed": no
electron-updater instance at all, because nothing here may write into
files a package manager owns. ZenNotes reads the same release feed the
real updaters read (latest-linux.yml from the newest release, a
two-line parse, a small numeric version compare), compares it with the
running version, and says the answer. A newer version gives "ZenNotes
X is available. This copy is managed by your package manager, so update
it there", with the desktop notification once per version and the
sidebar badge; being current gives "You're already on ZenNotes X"; a
dead network gives the error. The retry policy is the one the real
updaters use. No Download or Install button appears for these installs:
AppUpdateState gained `installable`, and the renderer hides the action
in the About page and the update notice when it is false. Official
deb, rpm and pacman packages and the AppImage keep their full updater.
Two development knobs, gated to unpackaged runs and ZEN_PERF=1, make
the path driveable on any platform: ZENNOTES_UPDATER_FORMAT=managed
and ZENNOTES_UPDATE_FEED_URL for a served feed. That is how every state
was verified live on macOS: a feed above the running version lit the
notice with no button, the sidebar Update badge, and an About page with
Check for Updates and View Release and no Download Update; a current
feed gave "You're already on"; a stopped server gave the error.
How to test locally: on Linux, install from the AUR (or unpack the
tarball), open Settings, About, and press Check for Updates. Before:
"Checking…" forever. After: the answer within a second or two, and the
sidebar badge when a version is out.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release branch for 2.43.0. Work accumulates here;
mainfast-forwards at release time.Shipped so far
Fix(updater): the AUR package finally hears about new versions (5cc5ccf, reported on Discord by unyanda)
On an AUR or tarball install, Check for Updates never came back: the About page sat on "Checking GitHub releases for updates…" and the launch-time check never noticed a release either. Those installs were handed to the AppImage updater, which refuses to run without an APPIMAGE marker and refuses silently, so the app's "checking" state was never left. A non-system, non-AppImage install is now its own case, "managed": no electron-updater instance, because nothing may write into files a package manager owns. ZenNotes reads the same release feed the real updaters read, compares it with the running version, and says the answer (available with the package-manager hint, up to date, or an error), with the desktop notification and sidebar badge.
AppUpdateStategainedinstallable; the renderer hides Download and Install for these installs. Official deb, rpm and pacman packages and the AppImage keep their full updater. Verified live on macOS through two dev-only knobs that force the managed path against a served feed: newer, current, and unreachable all behave.Verification
npm run typecheckclean; desktop suite 694 tests, app-core update-state and component suites green