Re: RFC: Changing version number at start of dev cycle instead of end

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]