libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: totally confused by versioning system of libtool...


From: Ed Hartnett
Subject: Re: totally confused by versioning system of libtool...
Date: Fri, 13 May 2005 10:34:27 -0600
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

Daniel Reed <address@hidden> writes:

> On Fri, 13 May 2005, Ed Hartnett wrote:
>> Bob Friesenhahn <address@hidden> writes:
>>> Yes.  Unless it is explicitly deleted.

>> Suppose that we discover a bug which doesn't require any API change to
>> fix, but which will cause he users' computers to go into self-destruct
>> mode, and catch on fire.
>   ...
>> But now, we have the additional option of deleting the version of the
>> library file that contains the bug, during the install of the next
>> version. Then, their applications would crash horribly. But at least
>> their computer would not explode.
>
> Do not simply delete the broken file, replace it.
>
> If libexample-0.0.0, which installs as libexample.so.0, contains a
> bug, release a bug fix libexample-0.0.1, which will also install as
> libexample.so.0, replacing the broken version.
>
> Programs that were running at the time of the upgrade will continue to
> use the buggy version (even if the file is removed from the directory
> hierarchy, it will be kept available for processes that had it open
> before it was removed).
>
> Programs that start after the upgrade will automatically use the new
> version, with no relinking or explosions, horrible or otherwise.
>
>
> Many projects will continue to make bug fix releases even if a newer
> API is currently under development--including Libtool itself. For this
> example scenario, if libexample-1.0.2 is the current release, but a
> critical bug is found in both it and libexample-0.0.5, then you can
> feel free to release libexample-0.0.6 and libexample-1.0.3 at the same
> time.

So this is not actually replacing libexample-0.0.5, it is adding
libexample-0.0.6, and the loader is smart enough to automatically use
that in preference to libexample-0.0.5.

Is that correct? And libexample-0.0.5 stays on the users' systems
until they feel like deleting it, but it is ignored by the loader
because a fresher version exists.

But I don't understand why it's not 0.5.0 and 0.6.0. That is, wouldn't
it be a case of incrementing the minor version number, the middle
number?

>
> People using software that depends on libexample's 0 series will get
> the bug fix without having to rebuild or, worse, rewrite their
> software.
>
> People using software that depends on libexample's 1 series should not
> be confused by the new release for the older 0 series, because 0.0.6
> is still less than 1.0.anything. The only down side is that installing
> libexample 0.0.6 might cause libexample.so to be re-pointed to
> libexample.so.0 and libexample 0's headers to overwrite libexample 1's
> headers, so software that is compiled after an upgrade might be forced
> to use the libexample 0 API and ABI instead of libexample 1's (which
> would not necessarily cause explosions, just different-than-expected
> but still functional behavior). The next time the libexample 1 series
> was upgraded everything would go back to normal.

But if we were updating two versions of our software at once, we
could do it in the correct order, so that libexample 1 is done after
libexample 0. Is that correct?

Thanks!

Ed

-- 
Ed Hartnett  -- address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]