This also allows embedded release notes to be plain text using sparkle:format="plain-text" attribute.
Also, Catalyst apps only support plain text release notes (compared to before where release notes weren't supported for Catalyst apps).
We fix the validation check for using the output option when multiple feeds are present, fix not generating new feeds when no prior feed is available, and fix incorrect logic with cleaning up delta files when multiple feeds are present.
Document --versions in generate_appcast better and add comments to explain why certain policies were made.
Add separate option to automatically pruned old update files. Now we only automatically move old update files aside. If the user passes --auto-prune-update-files we will also remove the old update files automatically.
Move old release notes files too.
Don't make old-updates directory hidden.
We preserve a batch of updates for each branch point (defined by an update's {majorVersion, minSystemVersion, maxSystemVersion, channel}). The latest for each branch point is used for generating delta updates.
We prune older update items that are no longer needed in the feed or needed for generating delta updates from newer items. We move pruned update files into a separate hidden directory, which is later garbage collected after a couple weeks based on each file's last modification date.
To insert new update items that are older than the latest update in the feed, --version flag needs to be used.
The overall goal is to have the feed only keep a small window of updates to serve to the user. This will also ease future processing generate_appcast needs to do and ensure the cache's directory doesn't blow up by pruning old updates.
We fix one memory leak when calculating sha's, one memory leak in the xar delta applying path, and avoid creating Bundles for reading the Sparkle framework version.
There are some other small leaks with the xar delta creation/applying code but since it's a legacy implementation and the APIs are undocumented I don't want to touch it too much.
The biggest culprit here is the leak when calculating sha's I believe, if you have many archive items.
* Use UniformTypeIdentifiers framework to replace deprecated types
kUTType* constants are deprecated since macOS 12. The UniformTypeIdentifiers framework is available since the macOS 11 SDK.
* Replace renamed constants
* Use API_AVAILABLE macro instead of __OSX_AVAILABLE
In generate_appcast we:
* Validate code signing integrity of new updates
* Add hidden flag to disable checking for nested code during validation
* Warn if new and old apps have differing signing identities when generating deltas
Accounts are intended to be used for when working on products that belong to different organizations. This way multiple keys related to Sparkle can be stored in the keychain.
We also add a --verify option to sign_update which allows verifying that updates are signed correctly.
This new format introduces:
* A new container format which stores metadata in a way that is more efficient for compression, decompression, and size. Creation time can be 2x faster, apply time can be a few seconds faster, size savings can be 500 KB - couple of MB due to metadata alone.
* An array of supported compression formats including lzma, bzip2, zlib and more. We now default to lzma which is as competitive as bzip2 (which we were using in version 2 format) in applying/creation times, but can save several MB on size.
* Tracking of files from an old app being replicated in different locations in the new app. This can track unchanged files being renamed and can result in significant savings if the files are large.
Version 2 format is still the default. To use version 3, pass --version=3 to BinaryDelta when creating a patch. We will switch the default to version 3 later. generate_appcast support is upcoming.
When we don't have any information for existing items, we have been appending new items below the existing ones. We should insert new items such that new items are inserted in order of version descending.
Add generate_appcast options for appcast selection features
We can now supply for new update items:
* Link
* Channel name
* Last major version / minimum autoupdate version
* Phased rollout interval
* Last critical update version
* Originating informational update versions
We can also specify the maximum number of delta items to generate.
Lastly we can specify which versions to create new items for now. This allows applying flags for only specific versions, or for exceptional cases allows adding old versions that do not meet the most recent updates threshold (maxNewVersionsInFeed) -- think for updates for a prior OS or for a prior major version.
We do not override the minimum system version element on already existing items now, if the element already exists. Apps don't strictly need to specify LSMinimumSystemVersion and this allows users specifying it themselves in the feed.
The help page for generate_appcast was expanded with how the archive directory looks like, how release notes work, that old entries are kept in tact, and how extracted archives are cached..
We now write out the number of new updates written and the number of existing items updated, to make the generated result be less confusing.
Bug fixes:
* The scheme now builds for Debug so I can properly debug generate_appcast from within Xcode (distribution builds are still in Release)
* Newly generated items were appended at the end of the appcast and not necessarily inserted in the correct order (on top). As a workaround when we process existing items, we remove them, and re-add them.
* Fixed an off-by-one error for maximum number of delta files we can generate.
Fixes#1903
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).
When archives are stored as symlinks e.g. due to storing binary files in a
git-annex repository, everything works file except file size in the generate
feed xml file. This patch makes generate_appcast correctly determine file size
by following the symlink
(cherry picked from commit 7233bb93e7)
Previously, generate_appcast could only add or remove the release notes element for an update. This was probably fine, because it was unlikely to change: the release notes URL was determined by the SUFeedURL.
However, now that —release-notes-url-prefix was added, the release notes element CAN change. So, with this commit, if the release notes element is present for an update, the URL will be set correctly.
(cherry picked from commit 7c7e924ed4)
Zorg
Eitot
Sungbin Jo
Lance Lovette
Gwynne Raskind
Denis Dzyubenko
Brad Andalman
Kornel
Rajiv Shah
Jordan Rose