Releases made by CI have funky version numbers

[pjrobertson]

To Reproduce

1. Push a new branch to the QS repo: git push origin v2.0.1
2. Wait for CI to create the build and make a release
3. Check CFBundleShortVersionString in the Info.plist. It's set to 2.0.1: (HEAD detatched at v2.0.1)

Expected behavior
For official releases (made by tags) they should just be named 'version number'. E.g. 2.0.1, but other builds should include the repo status

Screenshots

What version of Quicksilver?
All those built by GH Actions.

[n8henrie]

Plan to look at this today

[n8henrie]

This should trigger a new (test) release in a few minutes to make sure this works on CI, if so we can cut 2.0.2 soon.

https://github.com/quicksilver/Quicksilver/releases/tag/2.0.1-test-version-fix

[n8henrie]

Huh. That didn't trigger a release, and it has a trailing colon.

[n8henrie]

You can use this standalone script to see the logic and preview the NEW_VERSION_STRING that will end up in CFBundleShortVersionString.

I just ran a test on a new tag v2.0.3, and other than not having updated the version info (so the DMG had the wrong name as you can see), it seemed to work:

For all conditions other than a tagged Release build, it includes more contextual information.

#!/bin/sh
# Script to append development information to the QS version string

# Created by Henning Jungkurth on Apr 18 2012
# Modifications by Nathan Henrie on 20220405

set -euf

# Change these to see how they change the output
CONFIGURATION=Release
QS_INFO_VERSION=2.0.2

CURRENT_TAG=$(git describe --exact-match --tags 2> /dev/null || true)
CURRENT_BRANCH=$(git branch --show-current)
HEAD=$(git rev-parse --short HEAD)

# Default: `2.0.2:master-a83756f6:Debug`
NEW_VERSION_STRING=${QS_INFO_VERSION}:${CURRENT_BRANCH:-"deatched HEAD"}-${HEAD}:${CONFIGURATION}

# If on an tag, make prettier: `v2.0.2:Debug` or `v2.0.2`
if [ -n "${CURRENT_TAG}" ]; then
  if [ "${CONFIGURATION}" = "Release" ]; then
    NEW_VERSION_STRING=${CURRENT_TAG}
  else
    NEW_VERSION_STRING=${CURRENT_TAG}:${CONFIGURATION}
  fi
fi

echo "${NEW_VERSION_STRING}"
exit 0

if [ -n "${NEW_VERSION_STRING}" ]; then
  defaults write $QS_APP_CONTENTS_FOLDER/Info CFBundleShortVersionString "\"${NEW_VERSION_STRING}\""
fi

I think the associated PR is ready to merge if this looks okay: #2710

Once merged I think we should push v2.0.3 to fully resolve this issue.

[MiqViq]

		<key>CFBundleShortVersionString</key>
		<string>v2.0.2</string>

This version formatting is better now but still the best version number in CFBundleShortVersionString does not have anything but digits and dots...so I suggest that you use plain "2.0.2" style with public releases.

[skurfer]

I’m thinking the easiest way to fix this is to just stop putting ‘v’ at the beginning of the tags. It’s not like we’d look at a tag called “2.2.0” and not know what it was.

[MiqViq]

Yes, version numbers should start with digits only. I guess that something like 2.0.3b may be acceptable but it is best to use plain digits and dots.
I found this out the hard way as that starnge CFBundleShortVersionString with 2.0.1 messed up my Munki Repo catalog rebuilds...took few hours to figure out what was causing the issue. Well, now I know better...

[n8henrie]

the best version number

By best, do you mean the one you prefer based on aesthetics? Or did you mean something else?

I considered making it something different, but thought that having the release match the tag was best, and we've been using a v prefix for tags (which I've found useful in other projects a few times, gives you a nice | grep '^v[0-9.]+$ for filtering various things).

I made CFBundleShortVersionString match the tag name, so options that come to mind are:

• Leave it as is. I don't see a huge problem with a leading v, common in many projects, though I agree it might not fit everyone's preferences for aesthetics. It does help avoid issues with stringly-typed stuff getting interpreted as numbers and leading to sorting issues (i.e. numerous python 3.10 vs "3.10" vs 3.9 vs issues)
• Going forward, remember to stop prefixing tags with v as has been done up until now
• Strip all leading vs from the tag when creating CFBundleShortVersionString. Unlikely to be an issue, but if Quicksilver were to ever go to string-based releases like QS 17.9: victory obviously would need changing
• s/[^0-9.]//g (or alternative regex) when creating CFBundleShortVersionString

Looks like @skurfer beat me to the comment.

[n8henrie]

Huh, I've never heard of munki. What issue do they have with e.g. v2.0.1? I wonder if they're incorrectly interpreting version numbers as floats.