[libvirt] FreeNodeMemory

Daniel P. Berrange berrange at redhat.com
Fri Feb 6 11:34:16 UTC 2009


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 :|




More information about the libvir-list mailing list