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