Versioned AppImage filename breaks desktop entries and symlinks on every update

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Build, CI, or release tooling

Steps to reproduce

1. Download T3-Code-0.0.36-x86_64.AppImage into ~/Applications.
2. Create a stable-name symlink and a desktop entry pointing at it, so the app is launchable from the dock and start menu:

   ln -s ~/Applications/T3-Code-0.0.36-x86_64.AppImage ~/Applications/t3-code.AppImage
   # ~/.local/share/applications/t3-code.desktop
   Exec="/home/<user>/Applications/t3-code.AppImage" --no-sandbox %U
   

3. Launch the app and accept the in-app update to 0.0.37 ("Restart to upgrade").
4. After the app restarts, quit it and try to launch it again from the dock or start menu.

Expected behavior

The app remains launchable from the dock and start menu after an update. Whatever path the desktop entry pointed at before the update should still resolve afterwards.

Actual behavior

Nothing happens when clicking the icon. The update wrote T3-Code-0.0.37-x86_64.AppImage into ~/Applications and deleted T3-Code-0.0.36-x86_64.AppImage, leaving the t3-code.AppImage symlink dangling and the desktop entry pointing at a file that no longer exists.

There is no error surfaced anywhere - the desktop entry silently no-ops, so it isn't obvious the update was responsible.

Because the version is baked into the artifact filename, every single update renames the binary and breaks any symlink, desktop entry, dock pin, or script that referenced the previous name. resources/app-update.yml confirms this is electron-updater against the GitHub provider:

owner: pingdotgg
repo: t3code
provider: github
releaseType: release
updaterCacheDirName: t3code-updater

Worth noting the symlink is invisible to the updater by design: the AppImage runtime resolves symlinks before setting $APPIMAGE, so electron-updater only ever sees the real versioned path and could not repoint the link even if it tried. A stable filename is the only fix that works from the app's side.

Suggested fix

Set a version-free artifactName for the Linux AppImage target in the electron-builder config, e.g. T3-Code-${arch}.AppImage. The file then keeps its name across updates, electron-updater replaces it in place, and every launcher referencing it keeps working. The version is still visible in the GitHub release, in the app itself, and via --version.

If keeping the version in the filename is deliberate, an alternative is for the packaging to also install/refresh a .desktop entry and stable symlink on update - but that is considerably more machinery for the same outcome.

Impact

Major degradation or frequent failure

Version or commit

0.0.36 to 0.0.37 (x86_64 AppImage, stable channel)

Environment

Pop!_OS 24.04 LTS, kernel 7.0.11-76070011-generic, x86_64, GNOME

Logs or stack traces

No logs are produced. The desktop entry silently fails because its Exec path no longer exists:

$ ls -l ~/Applications/
-rwxr-xr-x 1 user user 164567598 Aug 31 20:07 T3-Code-0.0.37-x86_64.AppImage
lrwxrwxrwx 1 user user        62 Aug 30 20:16 t3-code.AppImage -> /home/user/Applications/T3-Code-0.0.36-x86_64.AppImage

The app launches normally when the versioned AppImage is run directly.

Workaround

Point the desktop entry at a wrapper that resolves the newest AppImage at launch time rather than at a fixed path:

#!/usr/bin/env bash
set -euo pipefail
APP_DIR="$HOME/Applications"
newest=$(find "$APP_DIR" -maxdepth 1 -name 'T3-Code-*.AppImage' -type f -printf '%f\n' | sort -V | tail -1)
ln -sfn "$APP_DIR/$newest" "$APP_DIR/t3-code.AppImage"
exec "$APP_DIR/$newest" --no-sandbox "$@"

Related: #5174 reports the same class of problem on Windows (Start Menu shortcut lost after Nightly updates) - different mechanism, but also an update that leaves the app installed and working while breaking the launcher that points at it.

Start with resources/app-update.yml, then locate the electron-builder configuration that controls the Linux AppImage artifact name. Confirm how the GitHub release updater handles the renamed artifact, and verify that an update preserves the stable path used by the symlink and desktop entry.