User preference to disable auto-update

[philrz]

Right now auto-update is always enabled on macOS and Windows. Let's imagine a scenario where the user intentionally wants to keep running a build that's different than the latest GA one. While they can install it and start using it, within minutes they'll be informed that the latest GA version has been downloaded/installed in the background and they will be given the option to restart into that new version now/later. This means they effectively can't quit & restart the app and remain on their different build. Therefore it seems like we'd need to have a Preference option to disable the auto-update.

One example use case for this involves Support. We may at some point want to offer special builds to users that provide early access to experimental functionality. We'd like them to be able to continue running such builds and quit/restart when they need to until they explicitly "opt in" to upgrade to a GA release.

Yet another example use case might just be a conservative user that likes to always manually upgrade so they can take their time browsing release notes and confronting the potential hit to productivity should they fear hitting new bugs or climbing the learning curve of new features in a new release.

[philrz]

Note that a community user in a public Slack message recently expressed what they believed was a valid reason to want to continue using an older release. If they happen to be on Windows or macOS, they'd only be able to use it for one session as long as they're Internet-connected since the auto-update would kick in. Just wanted to cite at least one real request for this in the wild.

[philrz]

@jameskerr recently expressed an interest in adding a user Preference to include support for auto-updates via Channels (https://www.electron.build/tutorials/release-using-channels.html). This would allow users to express a willingness to opt in to beta releases should we choose to start producing them. And this would seem like a logical place to also put in the option to disable the auto-updates entirely.

[philrz]

I did an exhaustive verification of this feature in a personal fork (based on Zui commit d938f8e) where I created GA-style releases tagged v1.5.0 (as a starting point to install as a user) and v1.5.1 (as a newer release I'd be prompted for as a possible update target). The tl;dr is that everything worked as expected.

Below are detailed notes on the variations I performed on macOS, Windows, and Linux. Before the steps in each block of bullets I've done just a "fresh" install of v1.5.0. Note that auto-update is not currently possible on Linux, so in those permutations, seeing the browser open to the expected download URL after consenting to update defines "success".

"On Startup"

• With the default Setting for Check for updates… ("On Startup"), confirm that it pops up the offer to upgrade to v1.5.1, but that I can cancel and relaunch and still be in v1.5.0
• With the default Setting for Check for updates… ("On Startup"), confirm that it pops up the offer to upgrade to v1.5.1, and that I can accept this offer and that it updates/restarts ok into v1.5.1

"Manually"

• Change the Setting for Check for updates… to "Manually" as soon as I launch. This is to simulate someone that intentionally wants to stay back on an older release due to some bug they're avoiding or some older feature they depend on. With it at this setting, hang out for several minutes and confirm I never get prompted about the availability of v1.5.1
• Leave it at this setting and restart, making sure once again that I'm not prompted about a new release even after waiting several minutes
• Select the Check for Updates pull-down option manually and make sure I get prompted about the newer release
• Decline the update and make sure it doesn't get installed and that I can restart the app and not get prompted
• Select the Check for Updates pull-down option manually, get prompted, accept the update offer, and make sure it does get installed

"On Startup & Daily"

• Change the Setting for Check for updates… to "On Startup & Daily" as soon as I launch, then leave it open for 24 hours and confirm that I get prompted

---

Finally, the two requirements described earlier in this issue that we did not end up addressing as part of the linked PR #2866 are tracked in new issues #2944 and #2945.

Thanks @jameskerr!