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(a)redhat.com>
>
> Tested-by: Victor Toso <victortoso(a)redhat.com>
>
> 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