Personally I don't see why auto-update is the job of the software... why not just use a system-wide package manager? I suppose on Mac or Windows, that means using the Store, which heavily restricts what software can do. How shortsighted...
I mean lets not pretend that's a good choice for either devs or users either. From the user side, you're a the mercy of how fast your distro decides to package new versions. For most things that's fine, but for your main product you might want something newer. Of course devs can setup their own repos but then the devs have to do additional packaging, host infra, etc.
From the dev side, getting packages accepted into various distros can be a pain in the ass. Just look at the recent blowup around the Python Cryptography package when they decided to add Rust and Gentoo's complaints.
[1]: https://github.com/docker/roadmap/issues/183#issuecomment-79...
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 :)
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-79...
There is a class of developers who feel very, very strongly that updating the user's software should be their decision, and not the user's. For the lazy or reckless user's own good, or whatever.
Edit: and I can’t help pointing out the irony of this being a consideration on a thread about Docker.
Here's a question:
Even supposing all we had is e.g. Debian distros, why does Docker Hub exist? Why not just host all the artifacts in some repository and allow `apt-get install docker-image-$image-name`?
Why do so many programming language ecosystems use their own package management (Python's PyPi and pip, Rust's crates, Node's NPM, ...)
I'm open to people's thoughts on the way in which this following analogy doesn't hold. But I think the general (and imo deeply unfortunate) answer is that the software can provide a better experience if it handles these things like self-updates, even if it shouldn't be its "job".
Because then you have to support maintaining your ecosystem in a dozen or more variations of OS ecosystems. Easier to bring your dep manager to the OS than the other way around.
Adding a new package often triggers a re-resolve of all installed versions. Whether any updates happen at that time depend on how you've set versions bounds: e.g. https://stackoverflow.com/questions/48911625/npm-how-to-inst...
> the conclusion that auto-updates are a "better experience"
I don't know that they are necessarily a better experience overall, but it is certainly a worse experience to run into a bug or limitation that has already been resolved in a newer version.