Currently throughout the dev cycle we stick on the current release
number. The release number in configure.ac is only changed by DV
when he is actually cutting the release.
With the python bindings now being split out, this is causing us
problems. The python code aims to build against any libvirt version
that exists, so for example, the new network events APIs in libvirt
will be included with version 1.2.1. So the python binding does
#if LIBVIR_CHECK_VERSION(1, 2, 1)
static void
libvirt_virConnectNetworkEventFreeFunc(void *opaque)
{
PyObject *pyobj_conn = (PyObject*)opaque;
LIBVIRT_ENSURE_THREAD_STATE;
Py_DECREF(pyobj_conn);
LIBVIRT_RELEASE_THREAD_STATE;
}
...
This works fine if a python release is built against a libvirt
release. It does not work if a python git snapshot is built
against a libvirt git snapshot. This is bad because it prevents
us doing automated builds of GIT.
The solution here is fairly simple. We should increase the version
number in configure.ac at the *start* of each release cycle. This
means that libvirt-python can use the next version number and things
will 'just work'. I don't think this is a burden really - we already
encode the next version number in our source code when tagging new
APIs or driver methods. We're really just bringing autoconf's view
of the version number inline with the rest of the code.
So if no one objects, we should immediately change configure.ac to
be 1.2.1
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list