We should recommend using sparkle:version and sparkle:shortVersionString elements inside the appcast item instead of inside the enclosure for consistency.
Delta updates do not need to specify sparkle:version, and can inherit the top level element. This clears up some confusion and reduces duplication (and reduces error proneness / saves me work when testing delta / info-only features).
This is also consistent with informational updates. Regardless whether you want to make an update informational only or not, the sparkle:version stays in the same top-level place.
This is a backwards compatible change. Very old versions of Sparkle (possibly up to a decade or more ago) have supported specifying sparkle:version as a top level item. Winsparkle supports it as well because it's needed for info-only updates.
This is only changing what we recommend / standardize. The attribute variants are still usable.
External tools relying on Sparkle's feed format may have to adapt to this standardization (they have always needed to support info-only updates with a missing enclosure which apps do leverage anyway).
I updated generate_appcast to prefer the element variants and updated the tool so it understands them (this was a bug).
We unify the user driver method showing the update to take a generic state object now. The current fields of the state object are its current stage, if it's user initiated, and if the update is a major one.
We also remove deprecated code paths that were complex to support and will otherwise generate in compile errors if people adopt the new API.
We don't have a dismiss method for every transition state and we don't want to. This should be up to the UI to determine how to transition from one UI state to another UI state.
When the update is shown to the user, the menu item for checking for updates is no longer disabled. Instead it is enabled, and when invoked, will bring the update to utmost focus back to the user again.
This is consistent with other options (eg Preferences...) that bring up windows. Improved user experience here is that updates are now less "lost".
We (re)define properties on SPUUpdater:
canCheckForUpdates - to mean that the user can check for updates (start a new update check or show the already present update frontmost)
sessionInProgress - to mean if Sparkle's internal driver / scheduler is running (i.e, downloading appcast or update, showing update, starting installation).
Testing WebKit2 is more important than testing sandboxed downloader service.
More people should be adding entitlements to their app for connection services, so we will do that in the test app too.
This reduces friction in creating a SPUUserDriver. This assumption that the calls could be made from any thread is a relic of the past of separating the user driver into a different process from the updater/scheduler, which is no longer sane or supported.
This should speed up things very slightly too.
This will increase the chance of a user driver implementing being able to show informational only updates. Also it's better to use a new method rather than re-use another existing one inappropriately.
Zorg
Kornel
Gwynne Raskind
Jordan Rose
Philippe Casgrain
Bryan Jones
Tony Arnold
Kent Sutherland