Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution

[Ilya Konstantinov]

Hi David,

Any comments ?

I'm delighted to see such a mature attitude in the project, an attitude which levels the project with those of giants like Microsoft and Sun, who go through the same kind of hoops to maintain binary compatibility.

BTW, I'm not a FreeType developer so I cannot address your specific comments and my feedback is just general thoughts.

   but there are still cases where a program obtains a FT_Face object
   through libfreetype7, then call an internal function in libfreetype6,

You're talking about libraries which accept/offer FreeType structures in their public APIs, e.g. (just an example -- I never checked) Pango exposes a PangoFont's underlying FT_Face via public API function  such as:
FT_Face* pango_font_get_freetype_face(PangoFont* font)
?

 - first of all, install the next release as libfreetype6. RIGHT !!

In case we aim for full compatibility and pose ourselves as an incremental release, right -- the name has to stay.

Some libraries allow themselves the privilege of breaking binary compatibility. For example, Qt does it routinely (i.e. Qt2 vs. Qt3 vs. Qt4). I wonder what makes FreeType different. Distros also acknowledge this right of libraries to break BC by issuing massive recompilations and changes in the names of packages (e.g. when libstdc++.so changes yet again in some binary-incompatible manner).

However, with FreeType being such a basic infrastructure library, we should try to ensure we've exhausted all options for keeping binary compatibility before we break it. An alternative is a Linux-style "no stable API" approach, which positions the software's dynamic nature (and developer's joy of being able to perform drastic revolutions without caring for consequences) above binary/API stability.