"Installed Applications.Version" math (910 is bigger than 1010???)

[Jaybone]

We've always had collections set up so that we could tell quickly which clients had installs of Java below a certain patch level.

Our criteria for this was to look for:

Installed Applications.Display Name is like "%java 8%"
and
Installed Applications.Version is less than "8.0.XYZ"

for 32 bit installs, and a corresponding collection for the 64 bit ones, where XYZ corresponded to the current version. Java 8 Update 91 was 8.0.910.

 

With the new version that came out the other week, Java 8 update 101, that version number is 8.0.1010. I'm wondering if that switch from 3 digits to 4 digits is significant, here, because...

 

The problem that we're seeing now is that these queries are returning unexpected results, with empty collections - e.g. saying that no Java installs are earlier than 8u101.

 

I created a new collection with the opposite criteria, instead looking for Installed Applications.Version is greater than or equal to "8.0.1010" (and later tried 8.0.1010.0). This new collection contains every computer with any version of Java 8.

 

Apparently either:

1. Config manager sucks at math, thinking that 910, 750, 650, etc are larger than 1010.

or, more likely

2 I'm not understanding version numbering

 

If 2. I'm thinking maybe that the leftmost digit is the most significant, so 9 is greater than 1?

 

Anyone have any insight into this?

[Jaybone]

After changing up my search terms, came across this same type of question on Technet, answered by Garth and others. https://social.technet.microsoft.com/Forums/en-US/0f096508-2440-456e-ae78-72f4e4271a89/installed-applications-version-is-less-than-sort-order?forum=configmanagerapps

 

Apparently it's a string comparison, not numeric, so yes, the leftmost digit being 9 vs 1 explains it.

[GarthMJ]

Yup that right.. You beat me to it. :-)