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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list