-
Notifications
You must be signed in to change notification settings - Fork 132
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
Update Modes #2866
Update Modes #2866
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
I've been doing some testing of this branch at commit 88e21cc using the Dev builds created here. This build intentionally has its The tl;dr is that I've found some happy paths where it seems to be working well, and also some buggy variations. I'll start in this comment by documenting what's working, then I'll open up separate comments with each of the observed bugs. The videos below show it behaving as expected in a "happy path" of default Zui Settings after a fresh install on all OSes as long as:
This first video shows it behaving as expected on macOS. Happy.mp4Important things to note:
Windows has a similar happy path, with the variation that after I click Install the newer version of the app is downloaded automatically but I'm placed into an installer workflow. If I proceed with the couple clicks that are highligthed by default, the app ultimately does relaunch into the new version. Windows-Happy.mp4Linux also has a fine happy path. Here the variation is that after clicking Install the user is brought automatically to the https://www.brimdata.io/download/ page in their browser, which is in keeping with the understanding that we've always lacked full auto-update support on Linux. The Linux Installation guidance on the Zui docs site already advise the user on the details of manual upgrades being required on Linux, so we're in good shape here. Linux-Happy.mp4Without posting yet another set of exhaustive videos, I'll also note another positive finding I had when testing on each OS and clicking Later when notified of the availability of the newer version and given the option to update. In each case when I clicked Later I saw the desired result of remaining on the currently installed release. This is actually a vast improvement over what we had before on macOS and Windows. In the past, clicking Later had the effect of only postponing the upgrade until the next time the app was closed and relaunched. That is, even when clicking Later, the new version was still downloaded and installed in the background, such that the next time I closed and relaunched the app I'd be on the newer version. Part of why I've felt the functionality in this PR is needed so badly is because what we had in the past made it effectively impossible for a user to remain on an older version, unless of course they happened to be completely cut off from Internet access. So, more 👍. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All bugs I'd found when testing the branch seem to have been resolved, so I'm 👍 on this merging. Once it's merged I'll plan to do a final/exhaustive verification of all permutations by creating a personal fork of Zui where I can do true GA-style older/newer builds with all the necessary secrets as a final assurance that everything that worked with Dev builds should work just as well when we do the next GA Zui release.
Add different modes to auto update.
Closes #1211
Closes #2303