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 veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list