Repository navigation
macOS: option to check for updates only at app launch #13478
|
With auto-update = check or download, Sparkle checks at launch and then keeps re-checking on a timer while the app runs. So the "Update Available" or "Install and Relaunch" prompt can appear mid-session, which is exactly when I can't act on it: relaunching a terminal kills live processes, ssh connections, and long-running agent sessions. If I defer, the staged dialog comes back later, still at a moment I can't act. In practice the prompt only ever shows up when it's not actionable. Launch is the one moment when the notification and the ability to act coincide: nothing is running yet, and window restore makes a relaunch cheap. Proposal: the update settings currently cover what to do (auto-update = off/check/download) and what to track (auto-update-channel = stable/tip), but when to check is hardcoded: launch plus a recurring timer. Add an option for that axis, for example auto-update-schedule = launch-only, with periodic as the default so today's behavior is unchanged. The meaning of off/check/download stays as it is; this only controls when the check fires. As far as I can tell Sparkle supports this already (disable scheduled checks, fire one background check at startup), so the change would be scoped to the macOS app layer. The current options don't cover this gap: auto-update = off means I have to remember to check manually, which in practice means never, and check/download interrupt mid-session. Related: #9056 explored heuristics for detecting bad moments (presentations, screen sharing). This is the deterministic complement: instead of guessing which moments are bad, only check at the one moment that is reliably good. AI disclosure: I used Claude Code to research Sparkle's behavior and to edit this text. The proposal and final wording are mine. |
Replies: 2 comments 14 replies
How about those who "never" restarts their computer or quits Ghostty 🙈 |
|
@bo2themax, hiding the bubble is an interesting idea and maybe worth discussing on its own, but I think it's about a different use case and problem. For me it's not about an active process in the current window. My actual setup right now: five windows, each with two to nine terminals open. That's what working with multiple AI agents looks like these days lol, and I suspect more and more people are landing on setups like this 😅 With a setup like that, relaunching the app is the expensive part: all those sessions are laid out just the way I need them, and resuming 20 sessions is exactly the work I'm avoiding. So I delay relaunching, and rebooting in general, as long as I possibly can. Hiding the bubble while a process runs wouldn't change any of that: there's almost always something running somewhere, and the moment there isn't, the bubble is back while relaunch is still just as painful 😬 There's a principle from TRIZ engineering that I really like: the ideal system is when the system is absent but its function is still performed. Applied here: the ideal update bubble is no bubble at all, with the update still happening at the right moment. Launch-only is basically that: one check at the moment when relaunch costs nothing, because nothing is open yet. If you'd like to see how it might look, I'm happy to contribute. |
|
restarting my computer is indeed the best time to do all updates. batch housekeeping i say : ) |
Ok, I believe it makes more sense to add an option to check, download & install updates if there are any. |
|
@bo2themax, oh yeah! Giving this a second thought, the way you suggest it would be a much more elegant way to do it! So instead of a new config option, it would expand the existing one: auto-update = off/check/download/install, with the last one being exactly check, download and install. The install would happen on app quit (Sparkle's native automatic mode): the update gets downloaded and staged silently during the session, and the swap runs after the windows are already gone. Launch stays instant, quit takes an invisible second longer, and the new version is just there the next time you start. With that, no bubble is needed at all for this mode: nothing to ask, so nothing to show. As a fallback for abrupt exits (battery died, forced reboot), the staged update could be finished later: either at the next launch (a purely local check for an already-staged update, no network on the startup path) or simply at the next proper quit. I suspect Sparkle's resumable updates machinery already handles this out of the box, worth verifying at implementation time. And it lands on the TRIZ ideal from above perfectly: the function (the update) performed, the system (the bubble) absent 😁 |
|
@yauyauyauhen I did some digging, current Working on a branch to make the Restart pill hidden by default, will close this discussion once it's merged. |
|
Can it be configurable? I like knowing when an update is ready, I almost never close the terminal unless there's an update.... |
You can use |
|
I prefer the previous behavior, where the update is installed, I'm notified and when I'm ready, I just need to restart the app for the update to take effect. If I change to check, I'll need an extra step.... |
|
You're welcomed to open another feature request discussion about it. |
#13623