RE: [ft-devel] Regarding the 2.1.10 release

[Turner, David]

Hello Owen,

> Do you have a planned timescale for when the final 2.1.10 is
> planned? If we can do the pango/opentype changes to make it 
> use the raw tables in the next few weeks, and still have a few
> more weeks to test that in HEAD, then that probably will work
> fine.
> 
I don't have a planned time-scale at the moment. I'm currently
struggling to find free time to even make the first 'stable'
release.

I also begin to believe that it may be better, at the moment,
to follow this release scheme:

- immediately release 2.1.10 with all memory optimizations
  disabled, keeping major library number as 6. This could be
  seen as an upgrade from 2.1.9, since there has been
  tremendous changes since.

- also release 2.2.0rc1, which should be the same code,
  except for the following:

    * memory optimizations turned on
    * major library version to 7
    * no more internal headers installed
    * big warnings at compile and installation time about
      what's going on.

- create a VER-2-1 branch in the CVS to maintain the 'stable'
  code in case of important bug-fixes (i.e. a need for 2.1.11)

- continue developing the 2.2.x in HEAD

2.2.0 should be considered a release candidate until we get acceptable
patches for at least fontconfig, libXft, Pango and Qt. I expect quite
a number of them before we're all satisfied.

Since I'm expecting a new baby in the next days (no kidding), I can't
make any promise for a time-scale. And FreeType old-timers already know
that each time I make such a claim, I end up delivering the goods much
later anyway :-)

Not to say that I wouldn't really like to make 2.1.10 as described above
ASAP. Werner, could you help here ?

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



> Another possiblity would be to up the major version of FreeType to
> allow people to keep using Pango compiled against the old version. 
> I don't think this is a good  idea - you can get bad problems if an
> application is linked  against libfreetype.so.6 but a library 
> it depends
> upon (fontconfig, Pango, whatever) is linked against libfreetype.so.7.
> 
> So, basically, changing the major version of FreeType requires
> immediately fixing uses of the internal headers and rebuilding all
> apps on the system. The main difference from not changing the
> major number is that innocent applications that don't use 
> FreeType internals also have to be rebuilt.
> 
> In terms of the opentype code ... I'd certainly like to see it
> being maintained someplace shared rather than copied around. My
> thoughts last summer are outlined in:
> 
> http://lists.gnu.org/archive/html/freetype-devel/2004-08/msg00036.html
> 
> Basically to redo the otlayout/ module in freetype CVS starting
> from the current Pango code. But I never really got everybody 
> "signed off on" that plan, and other development priorities arose.
> But I think it's still a good idea. Behdad Esfahbod (cc'ed) is
> starting to look at doing some major work on the opentype code
> in Pango, so maybe he'd be able to help out moving to an 
> independent code base.
> 
> (I think rewriting to use  Werner's validator should be done
> separately.) 
>    
> Regards,
>                                               Owen
> 
> [ Note, I'm away from my email until 3/31 ]
> 
>