>> 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
