[Feature] Appcast buildNumber and general update

[michelerenzullo]

I am proposing a new feature and a general update to the Appcast parser.

Main feature request:

It would be very useful for us to rely on the build number rather than just the version. We often use Internal App Sharing and TestFlight for testing, and we frequently have the same version, such as 2.7.8, but with increasing build numbers—sometimes as many as 10—like 2.7.8+b10. Since Upgrader doesn’t have an option to check for the build number along with the version, this is currently not possible. For example, testers might have 2.7.8+b1, while we actually want to notify them about 2.7.8+b9.

Appcast supports this feature, but from what I’ve observed in the Upgrader code, the XML parser is somewhat outdated and doesn’t include it. It seems to be based on a version older than 2.0, whereas is currently available 2.6.4. The feature I am referring to looks like this:

    <sparkle:version>1009</sparkle:version>
    <sparkle:shortVersionString>2.7.8+b9</sparkle:shortVersionString>

My proposed logic is that whenever there are two tags, such as sparkle:version and sparkle:shortVersionString, the first should represent the build number of the app, while the second should represent the version, e.g., “2.7.8” or “2.7.8+b9”. Conversely, when there is only a sparkle:version tag, this should handle the standard use case that doesn’t rely on build numbers.

This enhancement would be extremely useful for non-production environments (i.e., outside of stores).

Minor feature request:

It would be useful and likely easy to implement a new method to mark criticalUpdates.
Currently, we need to create a separate and explicitly mark it as a criticalUpdate. This ensures that every version <= the specified version is considered deprecated. For example:

<item>
    <title>Version 2.7.8</title>
    <sparkle:version>2.7.8</sparkle:version>
</item>
<item>
    <title>Version 2.7.6</title>
    <sparkle:version>2.7.6</sparkle:version>
    <sparkle:tags>
        <sparkle:criticalUpdate></sparkle:criticalUpdate>
    </sparkle:tags>
</item>

With Appcast >= 2.0, we could define criticalUpdates implicitly within the same release, avoiding the need for multiple entries. For example:

<item>
    <title>Version 2.7.8</title>
    <sparkle:version>2.7.8</sparkle:version>
    <sparkle:criticalUpdate sparkle:version="2.7.6"></sparkle:criticalUpdate>
</item>

This change simplifies the process by embedding the criticalUpdate information directly into the relevant release item, reducing redundancy and improving maintainability.

[michelerenzullo]

Made a pull request for the main feature request I needed. Needs some review and cleanup tho here: #481