On 4/28/07, Wolfgang Sourdeau <wsourdeau@inverse.ca> 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.