Summary

Sparkle currently automatically picks whether to show the build number (CFBundleVersion in Info.plist and sparkle:version in appcast) and "short version string" (CFBundleShortVersionString in Info.plist and sparkle:shortVersionString in appcast) when showing the user what version they have.

This kind of works, but for some apps (e.g. the one I maintain, MacVim), both short version and bundle version are useful info to have. Because of how it's set up historically, the "short version string" refers to the Vim version (e.g. 9.1.234), whereas the bundle version (e.g. 175) refers to the release number (which is incremented by 1 every time I make a release, but the Vim version could have jumped by hundreds). I would ideally like the UI to say "MacVim 9.1.234 (r175) is now available, you have MacVim 8.7.890 (r173)." Instead, Sparkle seems to always prefer short version string, and only show bundle version in certain special cases (if short version doesn't exist, or if both old and new builds have the same short version string).

While I could modify my short version string to include the bundle version as well (e.g. I can make it look like "9.1.234 (r175)" in the appcast and CFBundleShortVersionString), I don't really want to, and it seems to go against the official documentation saying that CFBundleShortVersionString should just be 3 numbers separated by dots.

Note that there is a SUVersionDisplay delegate but it doesn't quite do what I'm saying here as I don't see an easy way to customize both versions' strings, and there are places where that delegate isn't called (e.g. when Sparkle determines there is no new version and shows a "You're up to date" dialog.

Note that #1496 was asking for a similar thing.

Possible Fix

Is there a way that Sparkle can expose a setting like SUShowBothShortAndBundleVersion to allow us to customize the behavior? I think each app is always going to have their different ways of handling short vs bundle versions, as Apple makes these two fields pretty flexible meaning that it's up to each app to decide what these numbers / strings should mean. Seems like Sparkle could allow the developer to choose.

An alternative is just to provide a more generic API than SUVersionDisplay's formatVersion:(NSString**)inOutVersionA andVersion:(NSString**)inOutVersionB API. To me, it should just be something like that (NSString*) versionString:(NSString*)shortVersionString (NSString*)bundleVersion (or the API could just pass a version info struct so it's more extensible in the future if people want access to the pubDate or sparkle:minimumSystemVersion etc). So in my case, I could just implement it so that I have the following (pseudocode):

// Implementing SUVersionDisplay
string macvimVersionString(string shortVersion, string bundleVersion) {
  return "$shortVersion (r$bundleVersion)"
}

Version

2.2.2.