Re: [GD-DEVEL] [2.1.0] Bump freetype minimum version to 2.2.0?

Hi Frank,

On 2/11/07, Frank Warmerdam <[email protected]> wrote:
> Pierre wrote:
> > Hi,
> >
> > While working on a bug (http://bugs.libgd.org/?do=details&task_id=42),
> > I came across one of my todo for gd-2.1.0. I like to set the minimum
> > Freetype version to 2.2.0 instead of 2.x.
> >
> > Freetype stable branche is 2.3.0 now, 2.2.x is a couple of years old
> > and contains many critical fixes. It wil help a lot to clean up our
> > encoding support as well as improve the rendering quality.
>
> Pierre,

Thanks for your quick answer :)

> I see my moderately recent system is still using freetype 2.1.7, so I would
> have to say 2.2.0 is far from universal.

2.1.7 or earlier could be fine, they already contain most (or all)
FT_ENCODING definitions. But earlier versions seem to have troubles or
miss some of the declarations.

Which distributions still have 2.1.x?

Debian (which is quite late in the game in general) does have 2.2.1 in
their stable branches which are not really new either.

> Were there some things that you can't do if the minimum version is 2.1?

The stroker works better while its API has changed from 2.1 to 2.2. I
feel bad to add new features and add different implementations.
However I can disable it if compiled with 2.1.x.

More importantly how to build a project against 2.2.x is different
than 2.1.x (the include macros have been introduced, etc.). It will be
nice

>  Other
> than encouraging people to use a newer safer version of freetype, was there
> a reason to raise the minimum required version?

Yes, the fixes present in 2.2.x are important for the new features and
the cleaning of gdft code. It is still possible to get it work (while
making one feature or another optional) with 2.1.x. For example I
cannot  guarantee to support every encoding with old versions. They
will work at least as good as they work now, using well place #ifdef.

> I normally try to only raise the minimum required version for dependencies
> when I have a fairly comepelling reason to use new functions not available in
> older versions.

Same here but I like to get rid of the old code base, it will help us
to improve the library in a clean and efficient manner.

We have enough time to decide, and if it brings too much trouble to
move to 2.2.x, I will make all new features and important fixes inside
conditional build, if a decent version is available. Doing this way
will keep a complete backward compatibility (with all troubles ;).

--Pierre