On Wed, Jul 08, 2015 at 01:13:09PM +0100, Zeeshan Ali (Khattak) wrote:
On Wed, Jul 8, 2015 at 11:11 AM, Christophe Fergeau
<cfergeau(a)redhat.com> wrote:
> On Tue, Jul 07, 2015 at 05:27:39PM +0100, Zeeshan Ali (Khattak) wrote:
>> Hi all,
>>
>> Christophe pointed out that this and the previous patch binds API that
>> was added an year ago:
>>
>> commit: 03e0e79e07622496522609741734c2fdcacb5bf2
>> Author: Nehal J Wani <nehaljw.kkd1(a)gmail.com>
>> Date: Tue Jun 24 02:31:49 2014 +0530
>>
>> net-dhcp-leases: Implement the public APIs
>>
>> Introduce 3 new APIs, virNetworkGetDHCPLeases,
virNetworkGetDHCPLeasesForMAC
>> and virNetworkDHCPLeaseFree.
>> ---------------
>>
>> While I think 1 year old is pretty old enough to justify bumping the
>> dep to that version, Christophe thinks its still too soon. I'd hate to
>> go through the trouble of adding ugly #ifdef around these new API but
>> if others (I guess mainly Dan?) agree with Christophe, I can do that.
>
> 1 year being old/not old is not a very useful/convincing argument. What
> is more interesting is what (supported) distros are shipping (f21, el7,
> oldest ubuntu LTS shipping libvirt-glib, debian, ...).
For the record, I don't think upstream development should depend on
when distros decided to upgrade packages and their release cycles.
Ok, I'll call you next time I need to get something newish to work with
the RHEL6 glib ;)
Also keeping in mind that it makes very little
sense to upgrade libvirt-glib and not libvirt since libvirt doesn't
break any ABI/API.
Generally speaking, there could be security issues, critical bugs in
Boxes which require a libvirt-glib update to be fixed, ... where
upgrading just libvirt-glib would be much more convenient than upgrading
the whole stack. So all in all, this is just a tradeoff to make between
making our life easier, and (potentially) making distributions life easier.
Which can be a very uninteresting discussion to have if they all have a new
enough libvirt, hence my question about what they have..
Christophe