recommendations for handling Hyper-V version number

[Ján Tomko]

On a Wednesday in 2020, Matt Coleman wrote:
>Hello again,
>
>Hyper-V version numbers are not compatible with the encoding used in
>virParseVersionString:
>https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virutil.c#L246
>
>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.
>
>Is the output of virParseVersionString stored on disk at any point?
>Would changing its output type from unsigned long to unsigned long long
>cause any compatibility issues? That would allow “minor” and “micro” to
>be up to 6 digits each and would be a quick, easy change.
>

virParseVersionString is just an internal helper, those can be changed
at will if you don't break existing users.

The problem here is the virConnectGetVersion public API - we cannot
alter its signature.

One solution would be to introduce a new API (that possibly returns a
string), but it will take time until apps start using it.

Jano

>Thanks,
>Matt
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200924/fda2635d/attachment-0001.sig>