On 4/28/07, Wolfgang Sourdeau <[EMAIL PROTECTED]> wrote:
I don't see how keeping some variables around would not have been
possible. Even by noting them as "deprecated" and waiting for a few
more release before removing them. That's always the case during an
intelligent migration process. "GNUSTEP_INSTALLATION_DIR" is probably
a variable which was possible to keep and that most modules are
counting on...
Maybe the goals that were targetted are valid. Maybe they were reached
correctly. But it's also important to think about the people who
depend on such a package before causing so much incompatibility.
Unless you can prove that keeping things compatible would harm the
intended process, I consider that way of doing things as stupid.
For old applications, they will break one way or another.
If it is not by gnustep-make, it will be by others later.
The "2.0" release of gnustep-make is a good indication of major changes,
otherwise, it will be 1.14 as gnustep-base.
While I am not an official figure to say so,
most major updates usually break old application, like GTK-2.0, Lucene 2.0,
Ruby 2.0 (not yet), etc.
Usually the 1.9.x release are the last one for backward compatibility.
I think it is better to ask project maintainers to update for
gnustep-make 2.0.
Yen-Ju
Wolfgang
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
