Re: [PATCH] Framework shlib versioning

[Jeff Teunissen]

Nicola Pero wrote:
> 
> > The shared libraries are binary-compatible, but the shlib is not the 
> > whole of the framework, and maybe not even the most important part of
> > it (a framework needn't always have classes -- it may be only
> > resources and/or headers). Framework resources (or for that matter,
> > any bundle's) are not internal to its code, but part of the interface
> 
> It depends.  Resource files, just like symbols in object code, can be
> either public or private.  Making an assumption that all resource files
> are public is as wrong as assuming they are all private.

It's not an assumption -- it's part and parcel of how frameworks work. A
framework's interface version applies both to resources and to shared
objects contained in it. Resources are always public, and you can't "take
them private". You can put something in the docs saying that developers
using the framework shouldn't depend on foo.plist having particular contents
(or whatever), but nothing in a framework's resources is ever private.

> Developers should be free to choose their own policies and to decide if
> a change in the resources affects the interface version or not.

They are, just as a developer is free to make a library binary-incompatible
without revving the soversion.

> But the main point I think is just that when you install a new version,
> no matter if API compatible or not, you must not overwrite the old
> version.

Why? And I didn't say API-compatible, I said binary-compatible, meaning
"works with all binaries that were compiled with old version". API
compatibility, that's a different issue entirely. :)

[snip]

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/