[Xorg] Xevie addition to libXext

[Owen Taylor]

On Sun, 2004-08-01 at 20:31, Jim Gettys wrote:
> The other problem is that packaging extensions into
> a common library is that it means you can't deprecate/withdraw
> that extension without breaking applications that use
> unrelated extensions.
> 
> As history shows (PEX, XIE, to name a few) not all extensions
> succeed, and having such unrelated interdependencies are bad
> engineering.
> 

So, say we decide two releases from now that XEVIE was a mistake
and it needs to be withdrawn.

 - If we remove libxevie from the packages that we distribute
   any app that requires XEVIE will no longer work.

 - If we remove the XEVIE symbols from libXext, any app that
   requires XEVIE will no longer work.

What's the difference? 

> And then versioning also becomes interdependent between
> libraries, also potentiall causing havoc.

If you believe that minor library version numbers have value,
then yes, having separate libraries allows them to be
bumped separately.

I've never seen any evidence that minor library numbers do
any good. Because even in places like Linux that "have" them
they have no representation in the file format. I can link
a program against libxevie.so.1.1 and run it against
libxevie.so.1.0.

If fine-grained tracking of versions and capabilities are
needed then ELF symbol versioning is a much more powerful
tool. (I mean the basic Solaris style grouping symbols into
versions, not the GNU extension that allows multiple versions
of the same symbol.)

And as far as major version numbers go, the rule should be
simple. Don't change them! :-)

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20040802/b2bb2f2b/attachment.pgp>