On Thu, Jun 01, 2017 at 02:05:04PM +0200, Andrea Bolognani wrote:
> On Thu, 2017-06-01 at 12:21 +0100, Daniel P. Berrange wrote:
> > This is not that attractive from POV the language bindings.
> >
> > eg in the Go code, I need to make usage of the new APIs
> > conditional at compile time. For exam
On Thu, 2017-06-01 at 12:21 +0100, Daniel P. Berrange wrote:
> This is not that attractive from POV the language bindings.
>
> eg in the Go code, I need to make usage of the new APIs
> conditional at compile time. For example for the new APIs
> added in 3.4.0 I have code like
>
> func (v *Strea
On Thu, Jun 01, 2017 at 01:13:05PM +0200, Andrea Bolognani wrote:
Our current practice when it comes to bumping the version
number for libvirt is to do so immediately after a release,
eg. right after 3.4.0 is released later today someone will
push a commit that changes configure.ac to use 3.5.0 i
On Thu, Jun 01, 2017 at 01:13:05PM +0200, Andrea Bolognani wrote:
> Our current practice when it comes to bumping the version
> number for libvirt is to do so immediately after a release,
> eg. right after 3.4.0 is released later today someone will
> push a commit that changes configure.ac to use 3
Our current practice when it comes to bumping the version
number for libvirt is to do so immediately after a release,
eg. right after 3.4.0 is released later today someone will
push a commit that changes configure.ac to use 3.5.0 instead.
As a consequence, builds made from master will always carry
