Enhance NetSparkleUpdater app cast compatibility with Sparkle app casts

[Deadpikle]

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.

<item>
    <title>Version 2.0 (2 bugs fixed; 3 new features)</title>
    <link>https://myproductwebsite.com</link>
    <sparkle:version>2.0</sparkle:version> <!-- <-------- -->
    <sparkle:shortVersionString>1.5.1</sparkle:shortVersionString> <!-- <-------- -->
    <sparkle:criticalUpdate></sparkle:criticalUpdate>  <!-- <-------- -->
    <sparkle:releaseNotesLink> 
        https://example.com/release_notes/app_2.0.html
    </sparkle:releaseNotesLink>
    <pubDate>Mon, 05 Oct 2015 19:20:11 +0000</pubDate>
    <enclosure url="https://example.com/downloads/app.zip.or.dmg.or.tar.etc"
                sparkle:edSignature="..."
                length="1623481"
                type="application/octet-stream" />
</item>

To increase our compatibility with Sparkle, we should:

• [x] Add <sparkle:version> elements to our output app cast
• [x] Add <sparkle:shortVersionString> elements to our output app cast
• [x] Add <sparkle:criticalUpdate> elements to our output app cast (if needed)
• [ ] For the above 3 items, make sure we can read them in as well. Prioritize them over anything in the <enclosure>.
• [ ] Figure out if we can either get the orig. Sparkle lib to check sparkle:signature on read of an app cast in addition to sparkle:edSignature (unlikely given the way they init things for signature reading) or figure out a way to nicely tell our AppCastItem to write both sparkle:edSignature and sparkle: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...)

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 :)

[zorgiepoo]

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.

[johncclayton]

Info updates - I hadn't thought of that case, makes sense.

What is the use case for compatibility?

I can think of:

1. A NetSparkle based updater generating appcast files for consumption by the Mac Sparkle library, and vice versa.
2. Keeping feature/conceptual parity between the two.

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).

[zorgiepoo]

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.