Adds support for v1 compatible binary names in the bundler

[krlvi]

🚧 Work in progress abandoned 🚧
👉 This task was picked up in tauri-apps#10938

This allows users of a Tauri v1 application to be able to smoothly update to a Tauri v2 application via the updater.

Background:

This change in Tauri https://github.com/tauri-apps/tauri/pull/9375/files, which is noted as a refactor is in fact a breaking change as far as the app updater is concerned.

The impact is that because the binary now has a different name, it is not possible to smoothly update a Tauri application via the updater if the initial version of the app is using v1.x and the new version is using v2.x.

Related upstream issues

tauri-apps#10548
tauri-apps/tauri-docs#2523 (docs)

Approach:

I'm introducing here an option for the tauri-cli (tauri-bundler) for producing the same binary names it did in v1, allowing users to update the app via the updater. In order to enable this behavior, set the environment varible

V1_COMPATIBLE_BIN_NAME=true

Previously, the bundler did the rename just after building the binary. I poked and tried doing the same once again, but because quite a lot of the code in that bundler changed since that was merged, it felt possibly more error prone (since now the rest of the code can safely assume that the binary is the crate name)

So, instead, my approach is to do the rename the binary at the last moment (i.e. in the bundle_project function in eg. app.rs)

Steps:

• Introduce an env variable to enable the v1 behavior
• Support the v1 renaming behavior for:
• MacOS
• Windows MSI
• Windows NSIS
• Debian
• Fedora
• AppImage
• Tests?

[krlvi]

Hi @lucasfernog, I wanted to check with you, is this change something that we would be able to upstream in Tauri (when ready) or are there some other plans?

[lucasfernog]

absolutely, I asked Amr to take a look at this specific issue next week

[krlvi]

Okay just as an FYI, I have put development of this PR on hold because I have realized I don't have a good way of testing the Linux bundles myself

[Geometrically]

Hey, since this issue is affecting our desktop app in production, I went ahead and finished it using yours as a base :) Here is the PR:
tauri-apps#10938

[krlvi]

Hey, since this issue is affecting our desktop app in production, I went ahead and finished it using yours as a base :) Here is the PR: tauri-apps#10938

Thank you for picking this up, @Geometrically <3

[amrbashir]

Hello, and thanks for your patience. Over the past week, we have landed a few fixes and features to v2 and v1 to help fix migration issues between v1 updater and v2 updater plugin.

We strongly recommend that you update your app to latest tauri 1.8 and release a patch to your users, afterwards you can migrate to v2 updater plugin without a problem. tldr; <= 1.7 -> 1.8 -> 2.0.

Here is some links to the PRs:

• feat(updater): support updating using non-zipped files tauri-apps/tauri#10939
• refactor(updater/wix): launch app after update, maintain args tauri-apps/tauri#10966
• fix(bundler/wix): use product name to generate UpgradeCode for MSI tauri-apps/tauri#10967
• feat(bundler/nsis): store main binary name to be used in registry for future updates tauri-apps/tauri#10952
• fix(bundler): store and remove old main binary on updates if main binary name has change tauri-apps/tauri#10962
• fix(core): restart cannot handle binary name change on macOS tauri-apps/tauri#10991
• feat(core): restart() handles binary name change for macOS tauri-apps/tauri#11002
• refactor(bundler/nsis): fix migration from MSI to NSIS tauri-apps/tauri#10996

[ndom91]

@amrbashir thanks a lot for all of the work!

@krlvi I've got a PR open bumping to 1.8.0 👍