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). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list