The workflow assumes changelog and version information have been updated and the tag has not been created yet before running it. When the workflow finishes, it should take you to a release page with the uploaded binaries, where you can verify the final details and publish a tag officially.
Also the following improvements were made:
* Change CURRENT_PROJECT_VERSION to represent a monotonically increasing bundle version (starting at 2000)
* Add MARKETING_VERSION to represent marketing version of Sparkle, comprised of SPARKLE_VERSION_MAJOR, SPARKLE_VERSION_MINOR, SPARKLE_VERSION_PATCH, and the new SPARKLE_VERSION_SUFFIX for pre-releases.
* Verify code signing signatures of extracted SPM zip file in make release and CI
* Generate changes to Sparkle podspec, just like the Package.swift file, based on current marketing version
* Improve format of Info.plist version strings when appending git hash info, eliminating unnecessary whitespace
* Simplify validating that XPC Service versions align with framework version
* Handle lightweight tags in addition to annotated tags in release-move-tag.sh
Add entitlements to InstallerConnection and InstallerStatus services and add option to specify bundle id in the now renamed codesign_xpc_service.py script.
Assume that the updater will be run as a logged in user.
The command line driver and progress app aren't completely root safe anyway, and running the progress app under a different user could be quite awkward from root
This is now necessary for package type installations so we can know whether or not we should authenticate ahead of time.
Of course, we also verify that the download contains the type of installation we expect (because the appcast is not very trusted).
I need to at least look at:
* Automatic downloaded / silent updates
* Running updates as root user from beginning
* Status info query service
* Add guided flag in the appcast
We now use XPC for communication between Sparkle.framework and Autoupdate.
Autoupdate is now ran as a launchd agaent/daemon. (Most of the time, it acts as an agent).
Using XPC can only be done from non-sandboxed processes, so a connection and status service had to be created.
Currently, the GUI progress tool doesn't work properly, but everything else should be behaving like before.