Closed Deadpikle closed 1 month ago
The first two (<sparkle:version>
and <sparkle:shortVersionString>
) elements Sparkle has actually supported for over a decade (winsparkle supports them too) because of having informational updates (i.e updates without a download that have a "Learn more" button pointing to developer's website in user's web bowser, in case updating process gets hosed or some developers prefer to use this for paid upgrades..). Then I had realized it made more sense for them to be top level conventionally rather than the enclosure which should really be about the update download.
Info updates - I hadn't thought of that case, makes sense.
What is the use case for compatibility?
I can think of:
For (1) above - I'd like to know how many people are doing that - I'm guessing zero based on the assumption that most Mac devs run a Mac based build pipeline. Hmmm... (thinking out loud), I can't see this being a driver. Prove me wrong [Net]Sparkle community :-)
For (2) - it makes more sense to me and certainly helps cross over devs use each library if the features are the same - there is far less "re-learning" and the research/effort that has gone into make the feature in one library is simply reimplemented in the second.
One potential solution would be an "output mode" e.g. output as Mac Sparkle compatible or not. For the record I don't like the idea. This idea should be actively discouraged as it encourages multiple implementations which would be extremely hard to move away from once it hit production.
So far I'm voting for (2).
Info updates - I hadn't thought of that case, makes sense.
For us top-level version elements are also a reduction when we have multiple enclosure items (due to delta updates, or I guess different sparkle:os's here).
Support for sparkle:os, and being able to use the same appcast on different Sparkle implementations, is actually not that sound as it's currently implemented. While Winsparkle picks the most-matching enclosure item for example, Mac Sparkle just only looks at the first one so we don't "soundly" support having two different platform enclosures for the same item (though this is not hard to fix). Also we don't support sparkle:os at all for info-only updates so you can't make an item be info-only for Mac Sparkle but not Winsparkle.
The XML norm of doing things would be for deviated Sparkle implementations to use their own XML namespace for custom extensions, similar to how Sparkle extended RSS. But I think we're all way past that now so this is moot.
The original Sparkle library for macOS has released a 2.0 version, not to be confused with NetSparkleUpdater's 2.0 version. (Hooray for the original lib -- this was a HUGE undertaking by them!)
There have been some changes to the way they structure their app cast. Lines with arrows are NOT emitted by our app cast generator.
To increase our compatibility with Sparkle, we should:
<sparkle:version>
elements to our output app cast<sparkle:shortVersionString>
elements to our output app cast<sparkle:criticalUpdate>
elements to our output app cast (if needed)<enclosure>
.sparkle:signature
on read of an app cast in addition tosparkle:edSignature
(unlikely given the way they init things for signature reading) or figure out a way to nicely tell ourAppCastItem
to write bothsparkle:edSignature
andsparkle:signature
(hmmmm...the latter is hard because right now the app cast items/app cast writer have no clue which types of signatures are being used, and this was intentional...)<sparkle:channel>
Basically, it'd be nice if our app casts could be read by them or vice versa.
...or maybe no one here needs compatibility with the o.g. Sparkle library and we don't need to worry about this :)