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@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@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