4 ms·

Outside the Store, most Mac software uses Sparkle for updates, which gives you a nice UI with patchnotes and a choice to update or not (or even opt-in to automa

Outside the Store, most Mac software uses Sparkle for updates, which gives you a nice UI with patchnotes and a choice to update or not (or even opt-in to automatic updates if you're feeling brave): https://sparkle-project.org/ https://sparkle-project.org/

thih9 6y ago
It looks like this is the framework used by Docker Desktop too [1]. Perhaps they enabled auto updates by default? (I wouldn't know, I don't have any experience with Mac projects.) [1]: https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...
- yellowapple 6y ago
  Yeah, the problem is that Docker Desktop apparently downloads updates automatically in the background, and Sparkle by default apparently wants to kick off the install as soon as the download finishes. Which of course punts the concern from "Docker Desktop is installing potentially-broken updates without my consent" to "Docker Desktop is consuming network bandwidth - which might very well be metered - without my consent" - that is, hardly an improvement. If the Docker folks could not be actively hostile to user experience for two seconds, that would be great :)
haswell 6y ago
Interestingly, they appear to be using Sparkle [0]. Oddly, stephen-turner claims that Sparkle is part of the reason it's taking some time to fix the issue. Direct quote: > As said above, we're working on this: we're planning to download the update in the background and then give the user the choice whether to update to it on next start. It's taken a little longer than we hoped because the Sparkle framework we use on Mac doesn't expect that workflow: once the update has been downloaded, it wants to apply it without confirmation at next shutdown. We are keen to retain the invisible download but give the user a choice whether to apply it later. It's hard to understand why they're struggling with a problem that seems to be solved by every other app that uses Sparkle... - [0] https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...
- saagarjha 6y ago
  Yeah, Sparkle’s workflow is a bit weird like that. I think most developers just patch it to not do that but never contribute their code back :(
- eyelidlessness 6y ago
  I’ve only had the pleasure/pain of using Sparkle once, but it’s definitely not as simple to use as “every other app” might suggest. At least coming from the perspective of “I’ve only ever released one Mac app to the public.” I mean it wasn’t as complicated as modern web build tools, but it definitely needed some finesse.

thih9 6y ago

It looks like this is the framework used by Docker Desktop too [1]. Perhaps they enabled auto updates by default? (I wouldn't know, I don't have any experience with Mac projects.) [1]: https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...

yellowapple 6y ago
Yeah, the problem is that Docker Desktop apparently downloads updates automatically in the background, and Sparkle by default apparently wants to kick off the install as soon as the download finishes. Which of course punts the concern from "Docker Desktop is installing potentially-broken updates without my consent" to "Docker Desktop is consuming network bandwidth - which might very well be metered - without my consent" - that is, hardly an improvement. If the Docker folks could not be actively hostile to user experience for two seconds, that would be great :)

haswell 6y ago

Interestingly, they appear to be using Sparkle [0]. Oddly, stephen-turner claims that Sparkle is part of the reason it's taking some time to fix the issue. Direct quote: > As said above, we're working on this: we're planning to download the update in the background and then give the user the choice whether to update to it on next start. It's taken a little longer than we hoped because the Sparkle framework we use on Mac doesn't expect that workflow: once the update has been downloaded, it wants to apply it without confirmation at next shutdown. We are keen to retain the invisible download but give the user a choice whether to apply it later. It's hard to understand why they're struggling with a problem that seems to be solved by every other app that uses Sparkle... - [0] https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...

saagarjha 6y ago
Yeah, Sparkle’s workflow is a bit weird like that. I think most developers just patch it to not do that but never contribute their code back :(
eyelidlessness 6y ago
I’ve only had the pleasure/pain of using Sparkle once, but it’s definitely not as simple to use as “every other app” might suggest. At least coming from the perspective of “I’ve only ever released one Mac app to the public.” I mean it wasn’t as complicated as modern web build tools, but it definitely needed some finesse.