[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Stability of virsh / libvirt interfaces

On Fri, Aug 17, 2007 at 02:29:51PM +0100, John Levon wrote:
> This has probably been discussed before so apologies.
> What is the current status of the interfaces, especially libvirt and
> virsh? Are they guaranteed to be stable? Does this apply to every new
> interface as soon as a release is done?

  I will apply the same strategy as for libxml2/xmllint as this worked 
well for quite a few years:

     - once an API is published in a release version, I will make all 
       effort possible to never break an application using it, be it
       at the API or ABI level. The only exception to that rule would
       be if we can conclude positively that no app can use that API.
       For example we removed an enum from the API a month ago since
       there was no entry point where it could ever be used.
       Of course an error is possible but really the policy is clear
     - Adding APIs is fine as the project evolves is normal process,
       but based on my libxml2 experience I will try also very hard to
       not push too early so we don't have to pile up the various version
       (preceding from previous point as we can't remove once released)

Now for virsh, since it's an application it's a bit less crucial, but 
I will definitely try to follow the same policy.

> (I ask after noticing that virsh schedinfo can be used to *set*
> parameters!)

It's kind of an API extensions, i.e. adding set to an existing get
as long as I don't see how this could break, adding stuff should not be a
problem. What's the problem, if you're used only to read you pass only
2 arguments. To set you need more argument, somehow it's a new API
(from a textual API perspective).


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]