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

[Eric Blake]

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131211/b3ddef1b/attachment-0001.sig>