Hi, On Thu, Sep 23, 2021 at 03:24:22PM +0100, Daniel P. Berrangé wrote: > On Thu, Sep 23, 2021 at 04:07:17PM +0200, Victor Toso wrote: > > Hi, > > > > On Thu, Sep 23, 2021 at 11:47:58AM +0100, Daniel P. Berrangé wrote: > > > In order to auto-generate more of the language binding code, it is > > > desirable to know what libvirt version an API was introduced in. > > > We can extract this information from the .syms files and expose > > > it in the API description > > > > > > eg instead of > > > > > > <function name='virNodeNumOfDevices' file='libvirt-nodedev' > > > module='libvirt-nodedev'> > > > > > > we now have > > > > > > <function name='virNodeNumOfDevices' file='libvirt-nodedev' > > > module='libvirt-nodedev' version='0.5.0'> > > > > > > This will benefit this proposal: > > > > > > https://gitlab.com/libvirt/libvirt-go-module/-/merge_requests/7 > > > > > > Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> > > > > Tested-by: Victor Toso <victortoso@xxxxxxxxxx> > > > > Thanks, this definitely helps. > > > > Do you think it would make sense to add version metadata to other > > types such as structs and enums too? > > We don't have a direct record of versions for these things, so it > is not very practical. I did a bit of brute-force with `git log -S --source --reverse` to find the version of everything exported in 7.7.0 API description: https://fedorapeople.org/~victortoso/libvirt/libvirt-v7.7.0.json While I agree it is not practical to look at the version of each of those and properly document it in libvirt, we could use the above as a reference and build some sort of allowlist for types that are not properly documented and require new types from 7.9.0 onwards to be documented. Cheers, Victor
Attachment:
signature.asc
Description: PGP signature
