You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts #2223 and #2221 in favor of making a simpler and lower-risk change in having the updater / progress app wait for a threshold amount of time before replying back with the status info, in case the service gets the data very soon afterwards. Before with #2221, this regressed installing an update to an app that was already terminated (e.g. from sparkle-cli) where the delegate callbacks were being called out of order. Also, this improves not having the framework have to wait for a registration complete reply in the common case.
My change requires changes to generate_appcast, generate_keys, or sign_update
Only bug fixes to regressions or security fixes are being backported to the 1.x (master) branch now. If you believe your change is significant enough to backport, please also create a separate pull request against the master branch.
Testing
I tested and verified my change by using one or multiple of these methods:
Sparkle Test App
Unit Tests
My own app
Other (please specify)
Tested test app and cases in #2221 as well as sparkle-cli on an app not terminated and an app already terminated.
In file included from /Users/runner/work/Sparkle/Sparkle/Autoupdate/StatusInfo.m:9: /Users/runner/work/Sparkle/Sparkle/Autoupdate/StatusInfo.h:18:41: warning: auto property synthesis is synthesizing property not explicitly synthesized [-Wobjc-missing-property-synthesis] @property (nonatomic, nullable) NSData *installationInfoData; ^ /Users/runner/work/Sparkle/Sparkle/Autoupdate/StatusInfo.m:20:17: note: detected while default synthesizing properties in class implementation @implementation StatusInfo ^ 1 warning generated. In file included from /Users/runner/work/Sparkle/Sparkle/Autoupdate/StatusInfo.m:9: /Users/runner/work/Sparkle/Sparkle/Autoupdate/StatusInfo.h:18:41: warning: auto property synthesis is synthesizing property not explicitly synthesized [-Wobjc-missing-property-synthesis] @property (nonatomic, nullable) NSData *installationInfoData; ^ /Users/runner/work/Sparkle/Sparkle/Autoupdate/StatusInfo.m:20:17: note: detected while default synthesizing properties in class implementation @implementation StatusInfo ^ 1 warning generated. note: Using new build system note: Planning note: Build preparation complete note: Building targets in dependency order
…data (#2230)
Without this, critical update alerts may not show up as promptly as they should when automatically installing them.
This fixes a potential race issue where sometimes the automatic update driver on completion would sometimes not trigger to prompt an update alert immediately for critical updates. Note in this case, the update would still be installed on app termination and would still be scheduled to alert the user on the regular update check interval, so this issue is not severe.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This reverts #2223 and #2221 in favor of making a simpler and lower-risk change in having the updater / progress app wait for a threshold amount of time before replying back with the status info, in case the service gets the data very soon afterwards. Before with #2221, this regressed installing an update to an app that was already terminated (e.g. from sparkle-cli) where the delegate callbacks were being called out of order. Also, this improves not having the framework have to wait for a registration complete reply in the common case.
Misc Checklist
Only bug fixes to regressions or security fixes are being backported to the 1.x (master) branch now. If you believe your change is significant enough to backport, please also create a separate pull request against the master branch.
Testing
I tested and verified my change by using one or multiple of these methods:
Tested test app and cases in #2221 as well as sparkle-cli on an app not terminated and an app already terminated.
macOS version tested: 12.5 (21G72)