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).
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/