[Devel] Release of freetype 1.x

[Antoine Leca]

Hi guys,

THIS MAIL HAVE NOTHING TO DO WITH FREETYPE 2, THE CURRENT LIBRARY.
It is only about the previous version, which is not actively
supported.

If you continue reading, then you should be interested on the subject.
Ok, let's go on ;-).


I have noticed a package of the 1.x library on SourceForge.
<URL:http://sourceforge.net/project/showfiles.php?group_id=23617&release_id=41518>,
scroll until the pink-boxed package just below freetype 2.0.4.

As always, it shows the current problem that it depends from libintl
(a.k.a. GNU gettext), but this is at least quoted in the documentation;
however, it strikes me that if someone build a package for FT 1, then
s/he should provide TWO versions of the shared library, one WITH
the links to libintl DLL, and also one WITHOUT them (i.e. --disable-nls).
If there are no disagreement, I will add this to the instructions.

But the reason for my message is not this one.
The version proposed is coming from a snapshot, updated around March '01.
OK, that is partially my fault, as I miss time to update the CVS, so
a number of changes I am currently doing are not committed. I am really
sorry about that. Nevertheless, two of these changes are quite important:
 - the disabling of the TT interpreter is not done by default (see below);
 - the new licensing conditions, i.e. original FT *or* GPL, is not set.

What is really worrying me, is that it is tagged as... libttf-1.4!
As you know, there is NO official release of 1.4, at least not yet, even
if most of the files inside CVS (or in the snapshots) do carry this version
number. Moreover, if we do release it just now (i.e., before any commitment
of the changes I have envisionned), we will release something a bit
different,
as it will include fo example Werner's changes for OpenType 1.3...

As a result, the situation is a bit messy, IMHO.

I see basically two solutions:

- one is if the GnuWin32 project accepts to cooperate, and decretes that
this
1.4 release from them was in error. Then, we could proprely (and soon)
release
ourselves a "real" 1.4 version, with anything we currently have (this
includes
the change in licensing) and probably lacking testing, but this will then
allow
them to produce a correct 1.4 package (which would probably had to be named
1.4a, but that is another problem).

- the other is to "accept" the 1.4 release as they did; I believe we could
"release" posteriorly a "1.4.0" version, using the very set of sources they
did
use; then, almost immediately, we would release a 1.4.1 version, including
the
changes we currently have (and the change of licensing).

How do you vote for? I prefer the first, as it makes the scheme for
licensing
quite a bit clearer, but other than that I have no idea.
As soon as we agree on that, I will do the necessary commits.


Then, when it could has been tested a bit more (something I will do for the
PC
platform, as far as I can), we would then release a 1.4.x version(s), which
would be _final_.
That is:
 - no new feature, even for a change of specifications (the last features
added
were for opentype, for the lack of better place to do them; but we do have
other
projects that will supercede it, don't we; other than OT, the last added
feature
should be dated something as October '98, charmap enhancing...
 - in case of bug-fix, we'll do a bit a regression testing (to be defined
more
carefully) and then made available publicly a new 1.4.n+1 release.

How about this scheme? Advices? Improvements?


Antoine