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

[Daniel Veillard]

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 at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/