On Tue, Dec 02, 2003 at 06:24:49PM +0100, Sven Neumann <sven@xxxxxxxx> wrote:
> > i usually advocate the "let bump the major lib" on api/abi change
> > because it enable to track common problems:
>
> myself on this), we do exactly this. During a development cycle, each
> and every release is incompatible with the former release, that's why
That's, of course, factually wrong. Real incompatibilities have been very
rare in practise. What's true is that often a newer version provides
features not found in older gimps and vice versa. However, it still did
support the old api, which is IMHO the point.
> We use the same versioning scheme as almost all of the libaries we
> depend on. That alone is a strong argument to stick with it.
(Philosophically, I always had a problem with agruments of the form: the
others do it, so it must be right. libtool does a lot of things wrong,
e.g. forcing -fPIC and other things for no good reason. Just because many
packages use libtool, for example, does not magically make it correct).
> I doubt that you can find a release in the 1.3 cycle that is API and
> ABI compatible with another release from the 1.3 cycle.
Very often during the early 1.3 releases I simply re-linked gimp-perl.
For many plug-ins, I also just symlinked the old library name to the new
library binary, and only once had a problem with that. That's why I wrote
"factually wrong".
> admit that we don't go thru the hassle of checking this for each
> release but simply follow the policy of assuming that the API has
> changed. But I am pretty sure that it did indeed change for every or
> at least almost every 1.3 release.
Still, you don't bump the major library number, which is the standard and
historic way to do that, as you have special support from your dynamic
linker for that. Changing the name works, too, but I never understood why
the established and working scheme is not used by the g* community. yes,
many packages use it, but the majority of packages out there does not,
especially packages not within the gnome (and to a lesser extent gnu)
communities.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
