recommendations for handling Hyper-V version number

[Matt Coleman]

>> For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0,
>> so its “micro” is over 14 times larger than the encoding allows.
>> 
>> My current workaround is to truncate it to something that works (E.G.
>> 10.0.143), but that's clearly less than ideal.
> The problem here is the virConnectGetVersion public API - we cannot
> alter its signature.
I hadn’t realized this was exposed by the public API.

Since the API can’t change, should I update my code to only output 
major.minor instead of truncating micro to an incorrect/misleading 
value?

The downside of this is that Microsoft has referred to Windows 10 as 
“the last version of Windows” and Hyper-V versions are the same as the 
OS’s kernel version. So, this would result in libvirt’s Hyper-V driver 
reporting version 10.0 until Microsoft reconsiders that approach.

> One solution would be to introduce a new API (that possibly returns a
> string), but it will take time until apps start using it.
That would be necessary to be able to convey the full Hyper-V version,
but I’m not sure if that’s needed anywhere at the moment. Also, I’d
like to flesh out Hyper-V support within the current API before adding
new functionality.

Matt