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 i
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.
>
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 versi
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
