On Fri, Feb 06, 2009 at 12:21:30PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 12:15:02PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure. All public structures are part of the public ABI and channot be changed once added. In that case, when do you consider a .so bump an option?
Never.
So to put it bundly, then you have much confidence in your design skills if you never allow structures to be extended. What is wrong with releasing a new version of the API having these structures added, and deprecated logic/macro's for the functions that access them?
If a mistake / limitation is discovered in an API, then the solution is not to remove that API. The correct approach is to *add* a new API with the new desired signature / struct. This avoids breaking existing apps and preserves the ability to drop new releases into existing deployments without have to rebuild & change source all downstream apps. There is no compelling reason to bump the .so version when it is perfectly possible to add new APIs & structs without doing so. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|