Some software vendors only report a shorter version number than their actual version number, which causes problems, and is entirely too common. This is applicable on both Windows and Mac, and probably Linux as well. (I’m starting with the Mac example, then cover the windows case below)
In the case of HipChat, it will report it’s version number as
4.30.1 even if it’s actual version number according to it’s own about page is actually
versions of regapps "HipChat.app" or the file directly:
/Applications/HipChat.app/Contents/Info.plist gives me
In many cases I’ve come across like this, the
Info.plist also includes more version info that could be used to solve this problem, but not in the case of HipChat.
This would be all fine and dandy if HipChat always incremented one of the version numbers they report when they release an update, so
4.30.1 would become
4.30.2, but for whatever reason, this doesn’t happen and now you have a situation where there are 2 different versions of HipChat that both report themselves as
4.30.1 in the file system, even though one is actually newer than the other.
This makes it very hard to tell that a piece of software needs updated, when there is a newer version that is hard to distinguish.
I tried searching the filesystem for a long version number, but came up empty:
grep -rnw '/Applications/HipChat.app/Contents' -e '4.30.1'
I also tried to see if VirusTotal’s analysis would provide a more full version number: https://www.virustotal.com/en/file/b8c924798875f3d200b8243f452ced8eb22fd70d40320b812a37445f1f69fa73/analysis/
The best I can do is write a hacky relevance statement that checks both the version number and the file size of the executable to try to differentiate a newer version from an older version, but in a way that is actually a problem when newer versions are released, in that it won’t detect that as gracefully as relevance normally would:
not exists sizes whose(it = 4317632) of files "HipChat.app/Contents/MacOS/HipChat" of parent folders of applications "/Applications/HipChat.app" whose(version of it = "4.30.1")
This isn’t a great solution, but it is a solution. You could also check the SHA1 in addition to the file size to be more certain, but file hashing is slower than checking the file size, so always do that first. It might also be possible to try to tell this based upon the modification date of the file, but even that can have it’s own complications.
On windows, the problem is the same, but the solution is slightly better:
There version info reported in the registry is still truncated:
(it as string as version) of values "DisplayVersion" of keys whose(value "DisplayName" of it as string starts with "HipChat") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" of (x64 registries; x32 registries)
The solution on windows is to read the full version info from the file itself:
versions of files "HipChat.exe" of (folder it) of (it as string) of values "InstallLocation" of keys whose(value "DisplayName" of it as string starts with "HipChat") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" of (x64 registries; x32 registries)