Improve minimumSystemVersion to check for latest compatible version instead of just latest

[wartab]

• Electron-Builder Version: 25.0.5

• Node Version: 20.13.1

• Electron Version: 32.0.2
• Electron Type (current, beta, nightly): current

• Target: macos & Windows

It is nice to have a feature that checks for minimumSystemVersion, however if a user hasn't update their app in a while, the user will be stuck on the ancient version, despite multiple versions inbetween the current version and the latest version technically being available.

It would be nice to allow to download the last compatible version given minimumSystemVersion.

[beyondkmp]

Are you looking for this feature? （https://github.com/electron-userland/electron-builder/pull/8108)

[wartab]

No, this feature request is in response to that PR.

Example: Let's say one of our users uses Windows 7 on our app at version 1.0.0. Now we release 1.1.0, 1.2.0, all compatible with Windows 7. The user doesn't update while 1.1.0 or 1.2.0 is released. We release 2.0.0, which requires Windows 10. That user on Windows 7, still being on 1.0.0 won't be able to update to 1.1.0, because electron-updater only checks for the latest release.

The way we currently did handle this situation is by creating a new Github repo for every Electron version that drops support for some OS.

But this does force people to go through the "last" version of a repo and may force them to do two consecutive updates.

Note that the same issue exists for staged rollouts.

[mmaietta]

The way we currently did handle this situation is by creating a new Github repo for every Electron version that drops support for some OS.

Wow, this definitely seems like something electron-builder could handle internally.

I'm not sure how to handle this on electron-updaters side for GitHub releases since either the latest version would need a history of all previous releases (update metadata), or we need to fetch every release from Github and check the latest-.yml for it (could be VERY high latency for projects with hundreds of releases though). The downside is that I don't think that'd work with s3 and other publishers that don't have access to previous releases (I think) as latest-.yml is stored a root and there's no history of releases stored in there. I'm not sure how to approach this feature implementation requested

[wartab]

It does seem quite tricky, I agree.

I am considering trying to build this myself, since the next major Electron version will drop support for macOS10.15 and many of our customers are stuck on that version. However, I'm afraid that I'll not have the time to do this.

I'm down to share my solution if it happens to be generic enough.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[wartab]

I haven't been able to work on this yet, but it becomes kinda urgent as Electron dropped support for MacOS10.15 and the last version that supports reached EOL.

[mmaietta]

@wartab I think this should supply the functionality you need in order to block updates of specific versions off of custom logic you implement from your side: https://www.electron.build/electron-updater.class.baseupdater#isupdatesupported

It's post-download of the UpdateInfo so that you have access to all data related to the release.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[wartab]

Thanks, that seems quite useful at least for blocking the latest release. This is a much better more flexible approach than what I would have suggested.

However, I'm not sure if there is a way to do the thing that I described:

• User is on version 1.0.0 and is compatible with version 1.1.0, but not 2.0.0.
• Current version is 2.0.0.

Can you somehow force a specific (Github) release to be fetched to at least be on the last compatible version (1.1.0)?

This is also problematic because of staged rollouts.

• User is on 1.0.0 and is compatible with version 1.1.0 and also compatible with 1.2.0.
• We release version 1.2.0, but want it to only be available for 10% of our user base.
• The aforementioned user is part of the 90%.
• Currently, 1.1.0 will not be installable by our user.

[mmaietta]

Can you somehow force a specific (Github) release to be fetched to at least be on the last compatible version (1.1.0)?

No, there's no way for us to pull that data beforehand via a public API (for each provider [s3, github, bitbucket, etc.] would be needed for a generic solution, as well as rate limiting in the case of Github is a particularly nasty limitation of the public API). It'd require some "history" of releases metadata (on the server I suppose) that returns what versions are valid for a specific app version based on metadata qualifications. An easier route would be providing an API to electron-updater to determine what updates are supported, but then that's basically rewriting or reimplementing electron-updater

[wartab]

I'm not sure I follow what you're saying. I don't want electron-updater to perform the logic. Just provide an alternative version to download instead of /latest, if we notice it's needed.

The flow would be as follows:

• electron-updater checks /latest
• My own logic in the new isUpdateSupported notices that the latest version isn't compatible
• Checking some internal API that tells me exactly which version to fetch.
• Tell electron-updater to suggest that update instead.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[wartab]

Bot can't count.

[mmaietta]

Tell electron-updater to suggest that update instead.

Wait, isn't this no different than setting channel and then calling checkForUpdates again?

And yeah, looks like the bot can't count 😅

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment, or this will be closed in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity.