[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