Re: [ft] Library versioning

[Will Newton]

On Wednesday 29 June 2005 12:36, Turner, David wrote:

> We're distributing this code so that people can experiment with it (and
> many do), not rely on it on production releases. I suppose we should have
> used stronger wording.

I would suggest a define like ENABLE_EXPERIMENTAL_CODE or a configure flag, 
that way distro people can disable the code until it is ready for widespread 
use. 

> We try to upgrade the libtool version numbers with each release. See the
> file docs/VERSION.DLL which includes the following versioning table:

The libtool triple is CURRENT.REVISION.AGE. The libtool info docs say this:

"""
  Here are a set of rules to help you update your library version
information:

  1. Start with version information of `0:0:0' for each libtool library.

  2. Update the version information only immediately before a public
     release of your software.  More frequent updates are unnecessary,
     and only guarantee that the current interface number gets larger
     faster.

  3. If the library source code has changed at all since the last
     update, then increment REVISION (`C:R:A' becomes `C:r+1:A').

  4. If any interfaces have been added, removed, or changed since the
     last update, increment CURRENT, and set REVISION to 0.

  5. If any interfaces have been added since the last public release,
     then increment AGE.

  6. If any interfaces have been removed since the last public release,
     then set AGE to 0.
"""

>
>     release    libtool      so
>   -------------------------------
>      2.1.10     9.8.3     6.3.8
>      2.1.9      9.7.3     6.3.7
>      2.1.8      9.6.3     6.3.6
>      2.1.7      9.5.3     6.3.5

This seems to suggest only the REVISION has changed where perhaps AGE at least 
should have been increased because interfaces have been added.

> We plan to make a 2.2.0 release soon, with a major so number of 7 instead
> of 6, mainly because we want to enable some optimizations in our source
> code that break some libraries like Pango or FontConfig which have the
> nasty habit of using internal library function that are not part of the
> public API (this is different from using beta APIs from the public headers)
>
> However, the release won't appear until we also provide patches for these
> libraries. Some are already on their way. I guess we'll have to provide
> patches for FireFox and GWorkspace as well then.

This is the relevant Mozilla bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=234035

I will try and make time to audit the FreeType dependencies in Debian and 
check if they link against any of the FTC_ symbols. If there's anything else 
I can do to expedite the release let me know, it would seem to be a good way 
to get out of the current difficulties with versioning.