Update loop when local version is greater than remote version

[ghost]

To reproduce:

1. Install a local version that is greater than what is available on the server
2. Check for updates
3. Updater sees that we are running a greater version, and downloads remote version anyway
4. When update is applied, the freshly downloaded version gets cleaned up and the greater version is used instead
5. Repeat forever

The log shows the following:

2016-07-22 14:03:45> CheckForUpdateImpl: Downloading RELEASES file from https://example.com/assets/app
2016-07-22 14:03:45> FileDownloader: Downloading url: https://example.com/app/RELEASES?id=app&localVersion=0.7.5&arch=amd64
2016-07-22 14:03:45> CheckForUpdateImpl: hwhat, local version is greater than remote version
2016-07-22 14:03:45> FileDownloader: Downloading file: https://example.com/app/app-0.7.1-full.nupkg

We want to provide several of our customers with updated versions before general availability. I believe that not trying to upgrade if the local version is greater should be the correct behaviour.

[andymartinwork]

Indeed. Having to do the Mac squirrel version of the updates myself, I wrote a server which used node semver to compare the versions and only update the versions that are less than the ones on the server. Why would you ever want to downgrade your installed version?

https://github.com/npm/node-semver

[alfequilu]

@andymartinwork a downgrade would be a good option for a rollback scenario. Imagine you deploy a version to production with a nasty bug, Would be great to just remove the last version from the server and then the application would notice this and downgrade to the previous bug free version.

[Skywalker13]

@alfequilu IMHO downgrade is not the right way, you must bump the version again with the reverted changes.

[dbkr]

In any case, the current behaviour does not downgrade: it downloads the version advertised on the server and then launches the same, more recent, version that was running previously.

[andymartinwork]

Yes and it does this over, and over, and over with notifications. Not very good behaviour from a user's perspective.

This is pretty major if you want to release a more recent version of your app on your website before bumping the version on the auto-update location.

[anaisbetts]

While I'd tend to agree that being able to rollback is Useful, it also would make a lot of the code more error-prone, so I'm going to WontFix this. I would definitely take a PR to create a RollBack Version that would download an older version, repackage it, then create a new RELEASES file though

[dbkr]

This bug isn't about being able to roll back, it's about the fact that having a version that is newer than any on the update server causes the app to update to the same version in an infinite loop. It should either roll back to the advertised version or, as you suggest (and I vote), ignore the update altogether. Currently it downloads the advertised version, prompts to update, restarts the original, newer version and then prompts for an update again, in a loop.

[Skywalker13]

@paulcbetts please reopen

[andymartinwork]

@paulcbetts - please reopen. I think you may have got the wrong idea when closing.

This bug means that when the version of an update is less than the version in production, an infinite update loop is entered into. This has happened in production for users of my company's app and is honestly a major reason for looking at other installers in Electron. We even added a -no-update flag for our app as a workaround so our testers could do their job because of this.

Repeat - this is a major legitimate bug, please reopen.

[obermillerk]

Has this been resolved or did it just get closed? If it has supposedly been resolved, I'm still seeing it in electron 1.6.11 so would that be a problem with electron's versioning of Squirrel.Windows?

@bontibon @paulcbetts

[phw198]

@obermillerk I've upgraded from v1.6.0 to v1.7.8 (current latest stable) and the issue appears to be fixed.