Re: [libvirt] RFC: Changing version number at start of dev cycle instead of end
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). -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: Changing version number at start of dev cycle instead of end
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
Re: [libvirt] RFC: Changing version number at start of dev cycle instead of end
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 signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] RFC: Changing version number at start of dev cycle instead of end
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.
With the python bindings now being split out, this is causing us
problems. The python code aims to build against any libvirt version
that exists, so for example, the new network events APIs in libvirt
will be included with version 1.2.1. So the python binding does
#if LIBVIR_CHECK_VERSION(1, 2, 1)
static void
libvirt_virConnectNetworkEventFreeFunc(void *opaque)
{
PyObject *pyobj_conn = (PyObject*)opaque;
LIBVIRT_ENSURE_THREAD_STATE;
Py_DECREF(pyobj_conn);
LIBVIRT_RELEASE_THREAD_STATE;
}
...
This works fine if a python release is built against a libvirt
release. It does not work if a python git snapshot is built
against a libvirt git snapshot. This is bad because it prevents
us doing automated builds of GIT.
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
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
