Support multiple installer/bundle types per platform

[FabianLars]

Now with the introduction of .deb updater support our current json schema really shows its limits. It would also be a valuable addition for Windows though because support msi and exe sometimes makes sense (or at least so i was told).

About the Static JSON response changes required: Duplicate object keys are seemingly not well supported (understandibly since the specs highly discourage it) so i guess that's sadly out.

I feel like overloading the current object keys like x86_64-windows-nsis is a bit ugly but honestly not the worst.

Alternatively we could provide basically schema version 2 and use an array instead of an object, example:

{
  // Maybe rename platforms to better reflect what the array actually contains
  "platforms": [
    {
      "os": "windows",
      "arch": "x86_64",
      "bundleType": "nsis",
    },
    {
      "os": "windows",
      "arch": "x86_64",
      "bundleType": "wix",
    }
  ]
}

[FabianLars]

Starting to work on this. After a meeting with chip and tillmann it looks like the x86_64-windows-nsis approach makes the most sense. The logic i have in mind looks like this:

1. If dev sets target use this
2. If response only contains x86_64-windows, use this
3. If response contains x86_64-windows-nsis, use this for nsis installs
4. If response contains x86_64-windows-nsis and x86_64-windows use the first one for nsis and the latter one for wix
5. ~~I forgot~~

Any feedback on that?

One open question is: should it straight up fail if the response only contains x86_64-windows-nsis with the app being installed with wix or should the updater ignore the -nsis part if there's no other x86_64-windows/-* key and just install nsis over wix?

• imo it should fail with TargetNotFound

[Legend-Master]

If response contains x86_64-windows-nsis and x86_64-windows use the first one for nsis and the latter one for wix

Shouldn't it be NSIS checks for x86_64-windows-nsis and fallback to x86_64-windows while Wix checks for x86_64-windows-wix and fallback to x86_64-windows?

should it straight up fail if the response only contains x86_64-windows-nsis with the app being installed with wix or should the updater ignore the -nsis part if there's no other x86_64-windows/-* key and just install nsis over wix?

An extra field containing a condition so the decision can be made from the new update instead of relying on the older updater would be nice, but I honestly hate logics written in custom languages so I don't know

Or just fail would be fine, if people want to install anyways, just use x86_64-windows (feels so confusing to me to be honest but I guess something like this is unavoidable for things to be backward compatible, some good documentations would probably help with this)

[FabianLars]

Shouldn't it be NSIS checks for x86_64-windows-nsis and fallback to x86_64-windows while Wix checks for x86_64-windows-wix and fallback to x86_64-windows?

Yes, poor phrasing but that's what I meant

[kandrelczyk]

Hi,

I had a look at the code and it's pretty clear so I will give implementing this a try. It will take me some time as it's the first time I will be touching this plugin so if anyone will start working on this again let me know. @FabianLars can I reach out on discord with potential questions regarding environment setup and development or are there better channels?

[FabianLars]

Awesome! Happy to hear. And no worriws, take your time :)

We only have discord and github so I assume discord is the better choice for this (but whatever you prefer)

[XurxoMF]

This is exactly what I was looking for xD Glad to see that's under development.

[rahulharpal1603]

This is exactly what I was looking for xD Glad to see that's under development.

Yes, me too. I wanted the support for .deb in latest.json for a project that I am working on.

[kandrelczyk]

This is mostly done, just waiting on reviews and possibly some fixes after that. @FabianLars any idea how we can move this forward?

[rahulharpal1603]

This is mostly done, just waiting on reviews and possibly some fixes after that. @FabianLars any idea how we can move this forward?

About the PRs linked here, it will add support for .deb in latest.json right?

[XurxoMF]

Once this changes are merged, will the tauri-action get updated too to include multiple versions at once?

[kandrelczyk]

About the PRs linked here, it will add support for .deb in latest.json right?

.deb, .rpm for Linux and .msi, .nsis for Windows.

Once this changes are merged, will the tauri-action get updated too to include multiple versions at once?

Yes, the next step will be generating the latest.json with multiple versions. Didn't look into that yet but that shouldn't be complicated.

[XurxoMF]

Coool, I'm not using updates yet. My app is under development for at least 2 or 3 more months but I'ld like the have actions working with multiple files. I can's build for MacOS without it XD

[FabianLars]

This is mostly done, just waiting on reviews and possibly some fixes after that. @FabianLars any idea how we can move this forward?

I have to admit that i'm a bit out of the loop after Amr and Lucas took over. Looks like they're busy so i'll try to find some time to look at it.

Once this changes are merged, will the tauri-action get updated too to include multiple versions at once?

Yes, the next step will be generating the latest.json with multiple versions. Didn't look into that yet but that shouldn't be complicated.

It's indeed fairly easy and i should have a branch for that somewhere already (may need to be changed though, like i said i'm a bit out of the loop so idk what the PRs ended up doing)

[jLynx]

@FabianLars @kandrelczyk I'm the guy who added the .deb updater support. Is there any update on this or link to the PR? If not I'll do the development for this as we now need it too

[SimenZhor]

@jLynx I think this is the relevant PR that is being discussed here: https://github.com/tauri-apps/plugins-workspace/pull/2624

I'm also keeping an eye on this issue for .deb support :)

[lucasfernog]

so we don't expect to support dynamic update servers by perhaps adding another variable for the bundle type? I think that's ok since it would make the development a bit harder to manage (we would probably need to use a fallback default bundle type)

[FabianLars]

won't we just need a new {{bundle}} kinda thing in the endpoints url? doesn't sound too hard and if a server doesn't read it it basically just falls back to the old behavior. I don't see why we would have to change the response format (if that's what you meant?)

[jLynx]

I agree with @FabianLars. keep the current functionality but add the optional {{bundle}} that will basically overwrite everything and just return the bundle specified. We could simply do dmg,rpm,exe,msi,deb..etc and it would return the specified version

I think the {{bundle}} template approach makes a lot of sense, especially for dynamic update servers.

Currently, update URLs look like this:

https://api.example.com/v1/updates?target=windows&current_version=0.5.73

With bundle support, it could become:

https://api.example.com/v1/updates?target=windows&bundle=nsis&current_version=0.5.73

This approach offers several advantages:

1. Server flexibility - The API can make intelligent decisions about which bundle to serve based on availability
2. Clean separation - Bundle type is explicit in the request rather than encoded in response keys
3. Backward compatibility - If no bundle parameter is provided, fall back to current behavior
4. Analytics friendly - Easy to track which bundle types are most requested
5. Future-proof - Easy to add new bundle types without changing the response schema

The server-side logic could be something like:

if (bundle) {
  // Return specific bundle if available, or 404 if not supported
  return getUpdateForBundle(target, bundle, currentVersion);
} else {
  // Return default bundle (backward compatible)
  return getDefaultUpdate(target, currentVersion);
}

I think both the static JSON approach and the dynamic URL template approach have their place - static JSON for simple hosting scenarios, and dynamic URLs for more sophisticated update servers that can make runtime decisions.

[kandrelczyk]

@jLynx would this be part of this feature request or dynamic URL would be covered in another PR?

[FabianLars]

imo it doesn't necessarily have to be the same PR but it should be released together (on crates.io/npm)

[lucasfernog]

well the problem with the {{bundle}} arg is that we still let the updater checks to run in dev mode - which aren't part of a bundle. so in that case we would need to use a "default" bundle, maybe configured via an env var (that we instruct to be set in .cargo/config.toml)

[jLynx]

well the problem with the {{bundle}} arg is that we still let the updater checks to run in dev mode - which aren't part of a bundle. so in that case we would need to use a "default" bundle, maybe configured via an env var (that we instruct to be set in .cargo/config.toml)

@lucasfernog in that case can we just make an assumption based on the users OS if it cant work it out automatically? e.g mac = dmg, windows = exe... etc