[libvirt] RFC: Changing version number at start of dev cycle instead of end

Laine Stump laine at laine.org
Thu Dec 12 10:29:44 UTC 2013


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).




More information about the libvir-list mailing list