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

Disable of auto-update #1211

Closed
philrz opened this issue Nov 12, 2020 · 3 comments · Fixed by #2866
Closed

Disable of auto-update #1211

philrz opened this issue Nov 12, 2020 · 3 comments · Fixed by #2866
Assignees

Comments

@philrz
Copy link
Contributor

philrz commented Nov 12, 2020

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 as necessary 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.

Another variation of this came up while responding to community issue #2685. In brief, as a government agency, they summarized one of their policies:

...we cannot allow automatic download and install regardless of whether we are running in an Admin or standard user context. How can this be disabled?

In that case, just having a Preference would probably be inadequate since a user could conceivably just go into the Preferences menu and re-enable auto-updates. Therefore we likely would want to also provide an install-time option so that the app would never permit auto-update under any circumstances.

@philrz
Copy link
Contributor Author

philrz commented Apr 26, 2022

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

philrz commented Feb 16, 2023

@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 philrz changed the title User preference to disable auto-update Disable of auto-update Mar 14, 2023
@philrz philrz mentioned this issue Nov 28, 2023
4 tasks
@philrz philrz closed this as completed Nov 28, 2023
@philrz
Copy link
Contributor Author

philrz commented Dec 21, 2023

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!

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.

2 participants