A workaround version strings ...

[loceee]

An extension attribute.

#!/bin/bash

app="/Applications/YourAppHere.app"
comparelen=10

vers=$(defaults read "$app/Contents/Info.plist" CFBundleShortVersionString  2> /dev/null)
if [ "$vers" != "" ]
then
    versint=$(echo $vers | sed 's/[^0-9]*//g')
    major=$(echo $vers | cut -d. -f-1)
    lenmajor=${#major}
    (( lenmajor == 1 )) && versint="0${versint}"
    len=${#versint}
    if (( len > comparelen ))
    then
        verscomp=$(echo $versint | cut -c-$comparelen)  
    else
        padlen=$(( $comparelen - 1 ))
        verscomp=$(echo $versint | sed -e :a -e "s/^.{1,$padlen}$/&0/;ta")
    fi
else
    verscomp=0
fi

echo "<result>$verscomp</result>"

= Version Numbers you can actually do INTEGER comparisons for your deployment smart groups.

I am working on a complementary project to dynamically create these. They taste great with Patchoo.

Thoughts?

(or keep prodding JAMF here ... https://jamfnation.jamfsoftware.com/featureRequest.html?id=224)

[acdesigntech]

I'm doing something similar, just pulls the version number, removes the '.' characters, then I can do a < > comparison :D This is what drives my auto-patching scripts.

#!/bin/sh

if [ -e /Applications/Cisco/Cisco AnyConnect Secure Mobility Client.app ]; then
    AnyConnectVers=`defaults read /Applications/Cisco/Cisco AnyConnect Secure Mobility Client.app/Contents/Info CFBundleVersion`
    IntAnyConnectVersion=`echo "$AnyConnectVers" | sed 's/.//g' | cut -d ' ' -f1`
else 
    IntAnyConnectVersion="9999999999"
fi

echo "<result>$IntAnyConnectVersion</result>"

Only problem I run into is when versions go from a "3 digit" version to a higher "2 digit" version. Ex: Universal Type Client was at v2.1.1, but gets upgraded to v4.2... 211 is larger than 42, so yeah... so I have to make sure the comparison is for 211 < 420. Usually multiplying by 10 works, as long as it ends up with more digits than the current version... but in cases such as Flash Player - Was at v 11.4.138.168 (or similar, seems like every other day theres a damn FP update), and was upgraded to v12.0.0.70. Well that's a higher version, but a lower integer AND has fewer digits, so multiplying by 10 does not work here. Still trying to work out the details with that one... your script might work better in this case, @loceee

[mm2270]

@loceee - nice. I'm doing something very similar in some scripts I've been developing and testing. My approach is a little different than yours, but the concept is the same. I refer to it as "normalizing" the version integers. I'm also rolling these into scripts that pull down the current application patch version from a page hosted by the app/plug-in vendor and also normalize those so they can be compared against the current patch level on the Mac.

@acdesigntech - As you've found, its not always safe to simply delete the periods from the version string. Some applications you can always rely on for that method to work. Office 2011, for all its issues, at least always seems to follow the format of XX.X.X for its version info.
But a case where I've seen this fail is with a recent Firefox update. There was a version, 29.0.1 that preceded version 30.0. Just deleting periods from these, 2901 is larger than 300, so you'll run into a problem.

[wyip]

Nice! Kind of a bummer that I have so many "workarounds" in place in Casper, though.

I upvoted the feature request you linked since this should really be part of the product, but its already marked as "Not Planned" :(

[loceee]

I'm also rolling these into scripts that pull down the current application patch version from a page hosted by the app/plug-in vendor and also normalize those so they can be compared against the current patch level on the Mac.

This sounds cool. Are you going to share? A major issue though I've just realised is that " " blank is apparently < than any value... and JSS doesn't allow you to specify NOT " ".

This sucks.