[libvirt] RFC: TODO list for a 1.0 release

Jiri Denemark jdenemar at redhat.com
Tue Jun 5 12:55:26 UTC 2012


On Mon, May 21, 2012 at 10:27:38 +0100, Daniel P. Berrange wrote:
> We have mentioned a 1.0 release in passing a few times recently but we
> have never really set out a clear list of goals for such a notable
> release. This thread is an attempt to clarify such goals. To avoid
> making the 1.0 target too hard, we should aim for as *little* as
> possible on our TODO list. I think the priority here should be on public
> API level things, or core libvirt infrastructure, and not random impl
> details of specific hypervisors. In particular I think we should focus
> on things that make libvirt better to develop app against.
> 
> IMHO we should have the following things in the 1.0 release
> 
>  - List object APIs which directly return the object instance
> 
>     https://bugzilla.redhat.com/show_bug.cgi?id=636096
> 
>     * virConnectListAllDomains
>     * virConnectListAllInterfaces
>     * virConnectListAllNetworks
>     * virConnectListAllNWFIlters
>     * virConnectListAllNodeDevices
>     * virConnectListAllSecrets
>     * virConnectListAllStoragePools
> 
>     * virDomainListAllSnapshots
> 
>     * virStoragePoolListAllVolumes

I think 1.0 could be the right time to start using deprecating older APIs for
which we have a better equivalent (e.g., all the old List APIs would become
deprecated in 1.0).

By deprecating I do _not_ mean that we should start removing them. The APIs
would remain in the library for backward compatibility but they would be
clearly marked as deprecated (with a link to the replacement APIs) in the API
documentation. Such APIs would not get any new enhancements but bugs would
still be fixed if possible within the deprecated APIs design.

And we should make gcc emit compile-time warning when an application tries to
use them. This would be either turned on by default with an option to turn it
off or the other way around.

Jirka




More information about the libvir-list mailing list