Second PR for#47.

Previously, we were settingCFBundleVersion to the output ofgit describe --tags (vX.Y.Z orvX.Y.Z-N-gHASH for preview builds).

To support Sparkle, and potentially to avoid a breakage with macOS failing to update an installedLaunchDaemon when it can't parseCFBundleVersion, we'll conform the string to the specification.

Given that:

You can include more integers but the system ignores them.

We setCFBundleVersion to a value of the formX.Y.Z[.N] where N is the number of commits since theX.Y.Z tag (omitted if 0)

Sparkle did previously allow you to supply a manual version comparator, but it was deprecated to help requireCFBundleVersion start withX.Y.Zsparkle-project/Sparkle#2585

That issue recommends instead putting marketing version information inCFBundleShortVersionString, but that actually has even stricter requirements:https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring

Though not documented, from testing & reading theSparkle source, I discovered thatX.Y.Z.N+1 will be deemed a later version thanX.Y.Z.N, which is what we'll do for the preview stream of auto-updates.

For non-preview builds (i.e. builds on a tag), both version strings will beX.Y.Z.

Since we're no longer including the commit hash in a version string, we instead embed it separately in theInfo.plist so we can continue to display it in the UI: