RE: [ft] Library versioning

[Turner, David]

Hello Will,

> 
> If the interfaces are available in the standard headers and 
> shared lib then it is part of the API and removing it breaks that.
>
It is part of the public headers, which begin with the following
comment:

  /*************************************************************************/
  /*************************************************************************/
  /*************************************************************************/
  /*************************************************************************/
  /*************************************************************************/
  /*********                                                       *********/
  /*********             WARNING, THIS IS BETA CODE.               *********/
  /*********                                                       *********/
  /*************************************************************************/
  /*************************************************************************/
  /*************************************************************************/
  /*************************************************************************/
  /*************************************************************************/

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.

> Debian relies heavily on sonames for dependency management so you are more 
> likely to 
> see breakage there than elsewhere, we treat libraries with identical sonames 
> as drop in 
> replacements which is not the case here, hence the breakage.
> 

> I have also attached a diff of the dynamic symbols listed in 
> 2.1.7 and 2.1.10 and it looks like a number of things have been added (which 
> should increase libtool AGE anyway) and a few removed, although I'm not sure 
> how important those symbols are.
> 
We try to upgrade the libtool version numbers with each release. See the file
docs/VERSION.DLL which includes the following versioning table:

    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
     2.1.6      9.5.3     6.3.5
     2.1.5      9.4.3     6.3.4
     2.1.4      9.3.3     6.3.3
     2.1.3      9.2.3     6.3.2
     2.1.2      9.1.3     6.3.1
     2.1.1      9.0.3         ?
     2.1.0      8.0.2         ?
     2.0.9      9.0.3         ?
     2.0.8      8.0.2         ?
     2.0.4      7.0.1         ?
     2.0.1      6.1.0         ?

Are you suggesting that we're not upgrading the correct number. Until today,
each new release of FreeType contained additionnal APIs anyway. Only some
experimental ones have been removed.

> In terms of finding a solution to this problem, it would be 
> useful for Debian if there was another release of FreeType with only the 
> soname bumped. I do not want to change the library soname in Debian 
> unilaterally, because obviously that will break things when you bump the 
> soname in future releases. 
> Would this be possible?
> 

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.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)