Re: [Devel] 2.1.0 branch created

[Werner LEMBERG]

> I propose the following, please tell me if this is correct:
> 
>   - create a new branch from the current HEAD, called
>     "STABLE-2-0-6"
> 
>   - get rid of "VER-2-1-0"
> 
> would this be enough ??

I think so.  But maybe an expert in CVS things can comment this also.

> > Incrementally adding features (if possible) helps to reduce the
> > number of bugs :-)
> >
> Yes, but the internal re-design I have in mind is also quite
> drastic and will introduce its own bugs, so I was just wondering
> if we didn't better start 3.0 directly..

Do you think that your planned modifications changes FreeType a lot
if viewed from the application's side?  If yes, 3.0 is correct,
otherwise, I suggest we stay with the 2 series.

> This would also help debug the MLib earlier, which would be a good
> way to speed up the development of UniType (an upcoming font
> configuration database library)

Well, I think that the version numbers should reflect user-visible
changes, not internal ones.

> I tend to think that OOP is a good way to design code. You can do it
> with C, however the resulting code is generally more verbose and
> less clear than the corresponding C++ one..

AFAIK, it's easier to write a C++ wrapper around C instead of doing it
vice versa.

> So the question really boils down to:
> 
>   A - is there enough interest in a C++ version of the library
>       (and more especially a C++ native API)

The question should be: Is there enough interest in a C++ API?

>   B - would doing so drastically reduce our development time
>       (man-years ??)

I really doubt that.

> I wouldn't have a problem with switching to C++ if there is enough
> demand, I just don't want to do it for the wrong reasons..

I prefer C, but maybe this is only me...

> To make another clarification, the two proposals (C++ or MLib) only
> concern FreeType 3.x. As much as I'd like to be able to do it right
> now, it is not possible to use the MLib within the FreeType 2.x
> branch without breaking source and binary compatibility.
>
> That's mainly because the implementation of "FT_Stream" and
> "FT_Memory" are not compatible with those of "M_Stream" and
> "M_Memory". There are a few other subtle reasons that I won't detail
> there, but we simply can't use it in the 2.x family..

This is indeed an argument to start with a 3.x series, so it's up to
you.  In any case, the final library version will be set shortly
before a new release, so it doesn't matter how we call it right now.

>     I intend to cooperate with the Boost.Jam team, since Perforce
>     seems to be extremely conservative about the original Jam source
>     (and they have very good reasons for that).. This team is also a
>     lot more structured, opened and active, which means that I don't
>     fear spurious forks of their sources..

Good luck!



    Werner