Autoupdates to lower version with allowPrerelease=true using GitHub releases

[dchest]

• Version: 17.1.0

• electron-updater version: v1.14.1

• Target: macos

In a test project, I set autoUpdater.allowPrerelease = true and published it as v1.16.9-pre on GitHub as Pre-release. Then published v1.17.0-pre as Pre-release. v1.16.9-pre successfully autoupdated to v1.17.0-pre. Then I published v1.16.10 (no pre here) as Release (not pre-release) and my v1.17.0-pre got updated to it, which was unexpected.

The chain of updates:

v1.16.9-pre → v1.17.0-pre → v1.16.10

I think somewhere the version check is missing or misbehaving.

[develar]

Version check behaves so due to channel concept. But GitHub doesn't support channels... That's bug.

[dchest]

Can channels be supported on GitHub like on other services by publishing ${channel}-mac.json instead of latest-mac.json? Why is there a difference? Thanks!

[develar]

Why is there a difference

Because we ignore version in the channel file. GitHub release version is taken in account.

[develar]

Solution — downgrade to stable version must be allowed only and only if allowPrerelease is set to false.

[dchest]

I think it also should make sure it won't automatically downgrade, only upgrade to the latest stable if allowPrerelease is set to false, by making sure stable version is >= current prerelease version. For example, if I make a channel selector like this:

I don't want users to downgrade once they switch back to stable releases, I want them to upgrade to the next stable version once it's released and then keep updating to the next stable, ignoring pre-releases. (Downgrading is usually dangerous due to database migrations, new features, etc.)

[develar]

@dchest Sounds good. Please see original request — #1149

[develar]

@dchest @tvanro Well, you ask different things/defaults. And I don't want to complicate. allowDowngrade will be set by default to false and all smart logic will be removed. If you need to downgrade — set allowDowngrade to true explicitly. I hope it will make updater more clear, and more suitable for all users. No strange magic logic. Do you agree?

[dchest]

Thanks! It seems the following algo would work for both our cases when using a pre-release:

• allowPrerelease=false, allowDowngrade=false: won't downgrade to stable, will upgrade only when next stable >= current pre-release.
• allowPrerelease=false, allowDowngrade=true: will downgrade to the last stable (like now).

[develar]

@dchest Thanks for discussion. Custom logic removed, if you need to allow downgrade — you have to explicitly set allowDowngrade to true.

[dchest]

Awesome, thanks!

[develar]

Fixed in [email protected]

[akashnimare]

Is there any way to downgrade app to one stable version to the other one? For an example, if I released v1.1.0 and it was buggy and now wants to downgrade to the previous version which was v1.0.0. What combination should I use here? I was hoping allowDowngrade to true and deleting the v1.1.0 will work.

[jyu-te]

@akashnimare have you ever found the answer?