Let the user get the newest version from inside the game.
What exists already
Top bar. Shows "Version X is available" when a newer release exists (main/top_bar.gd, MusicServerClient.fetch_latest_client_version). The check is done (#12).
Server download routes./api/v1/download/windows and /api/v1/download/linux redirect to the newest release's .exe and .x86_64. /download/list lists the files.
Linux package. Releases now also have MusicPlayer_<version>_linux.tar.gz, with the icon, the menu entry and install.sh. There is no server route for it yet: Sansan/MusicServer#34.
Plan
Step 1 (small): download button.
Make the "Version X is available" label a button.
On click, OS.shell_open(server + "/api/v1/download/<platform>"), so the browser downloads the right file. Platform from OS.get_name().
macOS has no export in the workflow yet, so there the button opens the release page https://gitea.sanplex.xyz/Sansan/MusicPlayer/releases/latest.
Step 2 (optional): update in place.
Download the new file with HttpTransport, with a progress bar in a small popup.
Swap the files:
Windows: the running .exe can be renamed but not overwritten, so rename the running file to MusicPlayer.old.exe, save the new one under the real name, and delete the .old file at next start.
Linux: overwriting the running binary works. If the game was installed with install.sh, that is ~/.local/bin/music-player-randomizer.
Restart with OS.create_process(OS.get_executable_path(), []) and quit.
Skip it when the game runs from the editor (OS.has_feature("editor")), or when the folder isn't writable. Then fall back to step 1.
The About popup already opens on the first start of a new version (last_seen_version), so the user sees what changed.
Tests
The button is shown only for a newer version, and builds the right URL for each platform. Make the platform a parameter so the test can choose.
Step 2: the file swap logic tested on temp files; the restart itself can't be tested headless.
Questions
Is step 1 enough, or do you want step 2 (update and restart by itself)?
Should macOS builds be added to the release workflow? There is a macOS export preset, but no CI export for it.
Let the user get the newest version from inside the game.
## What exists already
- **Top bar.** Shows "Version X is available" when a newer release exists (`main/top_bar.gd`, `MusicServerClient.fetch_latest_client_version`). The check is done (#12).
- **Server download routes.** `/api/v1/download/windows` and `/api/v1/download/linux` redirect to the newest release's `.exe` and `.x86_64`. `/download/list` lists the files.
- **Linux package.** Releases now also have `MusicPlayer_<version>_linux.tar.gz`, with the icon, the menu entry and `install.sh`. There is no server route for it yet: Sansan/MusicServer#34.
## Plan
**Step 1 (small): download button.**
- Make the "Version X is available" label a button.
- On click, `OS.shell_open(server + "/api/v1/download/<platform>")`, so the browser downloads the right file. Platform from `OS.get_name()`.
- Linux gets the package, once Sansan/MusicServer#34 is done.
- macOS has no export in the workflow yet, so there the button opens the release page `https://gitea.sanplex.xyz/Sansan/MusicPlayer/releases/latest`.
**Step 2 (optional): update in place.**
1. Download the new file with `HttpTransport`, with a progress bar in a small popup.
2. Swap the files:
- **Windows:** the running `.exe` can be renamed but not overwritten, so rename the running file to `MusicPlayer.old.exe`, save the new one under the real name, and delete the `.old` file at next start.
- **Linux:** overwriting the running binary works. If the game was installed with `install.sh`, that is `~/.local/bin/music-player-randomizer`.
3. Restart with `OS.create_process(OS.get_executable_path(), [])` and quit.
4. Skip it when the game runs from the editor (`OS.has_feature("editor")`), or when the folder isn't writable. Then fall back to step 1.
- The About popup already opens on the first start of a new version (`last_seen_version`), so the user sees what changed.
## Tests
- The button is shown only for a newer version, and builds the right URL for each platform. Make the platform a parameter so the test can choose.
- Step 2: the file swap logic tested on temp files; the restart itself can't be tested headless.
## Questions
- Is step 1 enough, or do you want step 2 (update and restart by itself)?
- Should macOS builds be added to the release workflow? There is a macOS export preset, but no CI export for it.
Sansan
added this to the 1.6.0 milestone 2025-09-19 22:35:21 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Let the user get the newest version from inside the game.
What exists already
main/top_bar.gd,MusicServerClient.fetch_latest_client_version). The check is done (#12)./api/v1/download/windowsand/api/v1/download/linuxredirect to the newest release's.exeand.x86_64./download/listlists the files.MusicPlayer_<version>_linux.tar.gz, with the icon, the menu entry andinstall.sh. There is no server route for it yet: Sansan/MusicServer#34.Plan
Step 1 (small): download button.
OS.shell_open(server + "/api/v1/download/<platform>"), so the browser downloads the right file. Platform fromOS.get_name().https://gitea.sanplex.xyz/Sansan/MusicPlayer/releases/latest.Step 2 (optional): update in place.
HttpTransport, with a progress bar in a small popup..execan be renamed but not overwritten, so rename the running file toMusicPlayer.old.exe, save the new one under the real name, and delete the.oldfile at next start.install.sh, that is~/.local/bin/music-player-randomizer.OS.create_process(OS.get_executable_path(), [])and quit.OS.has_feature("editor")), or when the folder isn't writable. Then fall back to step 1.last_seen_version), so the user sees what changed.Tests
Questions
Download newest version of applicationto Download or update to the newest version from the game