I have some existing code which tries to read the current version of SQL Server that's installed for a particular instance name by using a WMI query. It checks the first dotted part of the VERSION (to trigger an Upgrade install) and the SPLEVEL (to trigger a Patch install). This has worked well up to now. (I need to be able to get the version programmatically and without actually opening an SQL connection to the instance.)
However 2017 and 2019 have done away with service packs, rendering SPLEVEL useless, so I'm looking for an alternative to determine when only an older CU is present.
According to the table of version numbers, on my fresh 2019 install with CU4 applied, I should be seeing a VERSION of 15.0.4033.1 and a FILEVERSION of 2019.150.4033.1 (the actual page has a typo in the latter).
However while I am seeing the matching FILEVERSION, what I see for the VERSION is still the RTM value of 15.0.2000.5. This is also confirmed if I look at the Advanced Properties in SQL Server Configuration Manager. (And FWIW I also confirmed that SPLEVEL was still 0.)
Oddly, if I connect using Management Studio then it does show the version as 15.0.4033.1.
I don't mind switching to comparing the FILEVERSION if that's what's needed, but what has me concerned are the "GDR Builds". Looking at the equivalent table from 2017, there doesn't appear to be any particular rhyme or reason and a more recent GDR build can have a lower version number than an older CU build.
How can I make sense of this? What even is a GDR build and where does it come from anyway? Is it safe to assume they'll never "upgrade" an install that already has some CUs applied?