version numbers backwards...

[digitalmoksha]

It seems that the version numbers are backwards. In RubyMotion., version maps to CFBundleVersion, and short_version maps to CFBundleShortVersionString.

In an OSX app, the CFBundleShortVersionString is the real app's version number, and CFBundleVersion is the build number. The build number should typically be an increasing number, and is usually pulled from the git commit, or something.

motion-sparkle seems to have these numbers backwards, and so creates the package with values such as this

Release 82 (0.8.1)
Version 82
Build 0.8.1

instead of the correct

Release 0.8.1 (82)
Version 0.8.1
Build 82

[webcracy]

Ouch, thanks for the report.

Do you think you can submit a PR? I'll take a look otherwise.

Cheers

On Aug 7, 2015, at 10:13, digitalMoksha [email protected] wrote:

It seems that the version numbers are backwards. In RubyMotion., version maps to CFBundleVersion, and short_version maps to CFBundleShortVersionString.

In an OSX app, the CFBundleShortVersionString is the real app's version number, and CFBundleVersion is the build number. The build number should typically be an increasing number, and is usually pulled from the git commit, or something.

motion-sparkle seems to have these numbers backwards, and so creates the package with values such as this

Release 82 (0.8.1)
Version 82
Build 0.8.1
instead of the correct

Release 0.8.1 (82)
Version 0.8.1
Build 82
—
Reply to this email directly or view it on GitHub.

[digitalmoksha]

No problem. I do have one, but it's built on the other PR's i've submitted (and one other one, which uses the ksuther xpc branch for supporting sanboxed apps). I have to figure out the best way to separate it out, then I will be happy to submit it.