.dmg files built with ULFO format (supported since macOS 10.11) can be
made with file sizes similar to gzipped archives and are more familiar
for most end users.
The DMGBackground.psd file is just a non operational archive of the
background image used to obtain the DS_Store file through Finder
operations.
Version 3.8.0 Beta 2 and later are able to update using the new EdDSA key.
Older versions will be able to update in two passes: to version 3.8.7
through legacy DSA signature, and afterwards to the latest version through
EdDSA.
Very old versions will have Sparkle check for https://vienna-rss.sourceforge.net/changelog.xml
which has also been updated with current URLs
(same for changelog_beta.xml and changelog_rc.xml)
- Switch to default location for project's derived data, as suggested in
https://developer.apple.com/forums/thread/678974 to avoid slow
resolution of package graphs;
- Search Sparkle binaries in ${HOME}/Library/Developer/Xcode/DerivedData
- Fix unfit localization of publication date in app feed;
- Remove old scripts, clarify which scripts are used in project;
- Make execution of scripts in "Prepare Upload" target independent of
dependency analysis.
This requires macOS 13 and Xcode 14.3 (Swift 5.8). The ProcessPredicateLocalizations source uses Regex, which requires macOS 13 and Swift 5.7. The ProcessPredicateLocalizations source also uses "bare slash literals", which is an upcoming feature of Swift that requires the `.enableUpcomingFeature` setting (Swift 5.8+) to work in Swift 5.8.
We stick to gzipped tarball for archives (still a good compromise
between compression level vs. memory and CPU required for decompressing),
but with a file extension which should be more familiar / explicit for
most users: .tgz instead of .tar.gz
Let `tar` determine the compression method to be used based on the file
extension given for the output archive.
This eases my comparative tests between various archive formats for
delivering Vienna.
The XPC services are now bundled in the Sparkle framework.
Since Vienna is not using sandboxing, the SUEnableInstallerLauncherService key is set to false.
Sparkle 2 uses XPC services, of which Vienna only needs the InstallerLauncher service. A prebuilt XPC bundle is provided in the SPM artifact, located under a SourcePackages directory in Vienna's derived-data path. The derived-data path or the SourcePackages directory cannot be referenced directly (i.e. there are no environment variables for these), so the path is referenced by going to BUILT_PRODUCTS_DIR instead and then two directories further up the directory hierarchy.
Sparkle 2 also uses a user-owned SPUStandardUpdaterController instance instead of a shared SUUpdater object. Since Vienna uses the Sparkle updater object in the main menu as well as the preferences window, it has to be used twice (s. https://sparkle-project.org/documentation/preferences-ui/). The preferences UI is controlled via Cocoa Bindings.
The Sparkle-setup.sh script is moved from a build action to a post-build action in the shared Vienna scheme, since Xcode does not guarantee that the Info.plist file is not copied over from source and preprocessed after the script is run (the result of which is that the update URL is not added). The workaround for the Xcode bug is no longer needed since Xcode 11.5.
- fix signature selection (the one defined in xcconfig) for deployment
- work around incorrect path for signing Sparkle's AutoUpdate.app
- make the script more verbose to ease investigation of the issue when
notarization fails
Vienna is no longer a dependency of Deployment target.
Instead, we save informations about environment during Vienna Archive's
post-actions, and we make use of these saved informations in target
Deployment.
Notarisation submission should occur between these steps.
Barijaona Ramaholimihaso
Eitot
Tassilo Karge