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