Favor sparkle:version and sparkle:shortVersionString elements over enclosure attributes

[zorgiepoo]

We should recommend using sparkle:version and sparkle:shortVersionString elements inside the appcast item instead of their corresponding attributes inside the enclosure for consistency.

Delta updates do not need to specify sparkle:version or sparkle:shortVersionString, and can inherit the top level elements. This clears up some confusion and reduces duplication (and reduces error proneness / saves work when switching between specific features).

This is also consistent with informational updates. Regardless whether you want to make an update informational only or not (or omit the enclosure), the sparkle:version / sparkle:shortVersionString 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 / sparkle:shortVersionString as top level items. Winsparkle supports it as well because it's needed for info-only updates.

This is only changing what we recommend / standardize. Developers can still use the attribute variants in the enclosure if they want to.

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, eg for major upgrades, anyway).

I updated generate_appcast to prefer the element variants and updated the tool so it understands them (this was a bug). I looked at the code that was looking for minimumSystemVersion and copied that.

Fixes #1207 as well.

Checklist:

• My change is being tested and reviewed against the Sparkle 2.x branch. New changes must be developed on the 2.x development branch first.
• My change is being backported to master branch (Sparkle 1.x). Please create a separate pull request for 1.x, should it be backported. Note 1.x is feature frozen and is only taking bug fixes, localization updates, and critical OS adoption enhancements.
• I have reviewed and commented my code, particularly in hard-to-understand areas.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• My change is or requires a documentation or localization update - requires website docs update which I can get to later (as well with everything else..)

Testing

I tested and verified my change by using one or multiple of these methods:

• Sparkle Test App
• Unit Tests
• My own app
• Other - generate_appcast

Added couple unit tests to make sure versions (element and attribute variants) are parseable.
Tested generate_appcast making sure it writes new entries with element variant, and that it can look up both attribute & element version variants from existing entries.

macOS version tested: 11.5 Beta (20G5042c)

[zorgiepoo]

cc @vslavik

[vslavik]

To be clear, "favor" means in documentation here, the code still gives enclosure attributes higher priority as far as I can tell — i.e. item version is only used of the enclosure doesn't say otherwise.

That seems reasonable to me and is how WinSparkle behaves too (although mostly be accident, I think, and the support you refer to probably originates from those decade-old versions of Sparkle...

[zorgiepoo]

Yep, that's exactly it.