Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoupdates to lower version with allowPrerelease=true using GitHub releases #1497

Closed
dchest opened this issue Apr 24, 2017 · 13 comments · May be fixed by qcif/data-curator#563
Closed

Autoupdates to lower version with allowPrerelease=true using GitHub releases #1497

dchest opened this issue Apr 24, 2017 · 13 comments · May be fixed by qcif/data-curator#563

Comments

@dchest
Copy link
Contributor

dchest commented Apr 24, 2017

  • 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
Copy link
Member

develar commented Apr 24, 2017

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

@dchest
Copy link
Contributor Author

dchest commented Apr 24, 2017

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
Copy link
Member

develar commented Apr 24, 2017

Why is there a difference

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

@develar
Copy link
Member

develar commented Apr 24, 2017

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

@dchest
Copy link
Contributor Author

dchest commented Apr 24, 2017

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:

screen shot 2017-04-24 at 18 58 48

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
Copy link
Member

develar commented Apr 24, 2017

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

@develar
Copy link
Member

develar commented Apr 24, 2017

@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
Copy link
Contributor Author

dchest commented Apr 24, 2017

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
Copy link
Member

develar commented Apr 24, 2017

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

@dchest
Copy link
Contributor Author

dchest commented Apr 24, 2017

Awesome, thanks!

@develar
Copy link
Member

develar commented Apr 24, 2017

Fixed in electron-updater@1.14.2

@akashnimare
Copy link
Contributor

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
Copy link

jyu-te commented Feb 22, 2021

@akashnimare have you ever found the answer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants