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.
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.
Zorg
Tony Arnold
Kent Sutherland