-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Roadmap for Sparkle #992
Comments
Hm... I still think we have the right defaults (or are very close).. macOS is still a different environment than iOS and should be treated as such. I don't think updates default to be installed automatically on the Mac, but I'm not sure. It's different. I still think automatic downloading of updates should be opt-in by the user or developer. I don't know about everyone else, but a fair number of apps I use and develop don't have much internet connectivity. I almost feel that what Chrome does may be a special case and they can afford to get away despite their behavior. By nature apparently, updaters even tend to get auto-updating fatally wrong (see past corrupt updates, other popular macOS updater that fails at authorization). I think we are in need of a UI refresh or alternative along the lines of #127. Not notifications (#924). I may even go as far as saying supporting notifications would allow apps to enable intrusive behavior. Either way, notifications are supplemental, not an alternative. An unread dock badge is another similar idea, but I'm not sure it'd work out well. Having an update permission prompt.. I think we currently default to the "safe" choice because we can't force a developer to provide a reasonable option to disable automatic update checking. Hm, I do see the appeal of not bothering users with the prompt though.. :/ If we present that an update is available before installing, I believe we should show available release notes right there. If an update has been installed automatically without prompting the user, it may be reasonable to show new features (if the version upgrade was 'noteworthy' enough?). It's questionable how much of this logic should even be tied into Sparkle, as well as noting that the app could be updated manually as well. I feel that a separate supplemental app would most likely be installed and used by power / administrative users. It could be nice though. We don't want to go down the path of Growl where a pref pane was needed, third party apps installed the pane without user's permissions (against Growl's wishes), etc.. They eventually ditched the pref pane. |
One more thing that wasn't brought up for that I feel a tiny bit critical about: we default to scheduling updates repeatedly during the updater's lifetime. |
A separate updater should never be a requirement; applications should always be capable of updating themselves. However this is an awesome opportunity to develop an optional updater application! For example:
The Updater App would be a great tool to see all modern Sparkle applications on the system, versions, release dates, and the ability to update anything or everything if an update is available. Kind of like AppFresh or MacUpdate Desktop (I’ve never tried either of these, though, but are mentioned for reference). |
It would be great if Sparkle Updater App manages all updates system-widely. It can:
Updater App can discovery app by scanning SUFeedURL in Info.Plist . An annoying thing I've experienced with Sparkle is similar to #901. App says it has an update, but download failed after long time waiting because networks is poor. During the download, the status window is unable to hide or minimize. When the next time app starts, same thing happened again. |
Yes, definitely. We would really welcome enhancements that offer
|
Security is still my No. 1 concern. We are using Sparkle for a Sandboxed application, and thus can offer no "Install and Relaunch" due to the myriad security problems with doing this in current Sparkle and the branches that exist offering to do it while downgrading security. Been following this thread foreverrrrr so apologies if I'm not all caught up on the latest developments completely. Anyway, that's more important to me than anything else, because as it is now we can only use Sparkle to notify the user that there's an update available for them to download and install themselves. Without that many of the other improvements made to Sparkle are not something I can take advantage of. That said, there's nothing wrong with a nicer UI and the other improvements you're thinking about! |
@billymeltdown I think #1023 would be most relevant to you; pulling in the secure sandboxing branch I've been working on for a while. |
@zorgiepoo thanks, will check it out! Thanks also for all your hard work on this :) |
Sparkle is almost 10 years old. I suspect that users' and developers' expectations and requirements have changed since Sparkle was first released, so it might be worthwhile to discuss how updates should work in 2017.
Questions:
Should we redesign our UI?
Should we change our defaults?
Would it make sense to have a Pref pane, or a standalone app to manage Sparkle system-wide? To apply updates system-wide?
The text was updated successfully, but these errors were encountered: