[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ft-devel] Regarding the 2.1.10 release
From: |
Turner, David |
Subject: |
RE: [ft-devel] Regarding the 2.1.10 release |
Date: |
Wed, 30 Mar 2005 11:05:11 +0200 |
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 ]
>
>
- Re: [ft-devel] Regarding the 2.1.10 release, (continued)
RE: [ft-devel] Regarding the 2.1.10 release,
Turner, David <=