[libvirt] RFC: Changing version number at start of dev cycle instead of end
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 :|
On 12/11/2013 09:44 AM, Daniel P. Berrange wrote:
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.
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
Makes sense to me, but I'd wait for DV to concur. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Wed, Dec 11, 2013 at 11:59:55AM -0700, Eric Blake wrote:
On 12/11/2013 09:44 AM, Daniel P. Berrange wrote:
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.
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
Makes sense to me, but I'd wait for DV to concur.
ACK Daniel
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
-- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 12/11/2013 06:44 PM, Daniel P. Berrange wrote:
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.
An added advantage for those of us using Fedora with the virt-preview repo enabled will be that a "yum update" will no longer replace our brand new locally-built libvirt with one from virt-preview just because it has an "extra" version > 1 (e.g. 1.2.0-2).
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Laine Stump