[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release schedule

From: Tim Harrison
Subject: Re: Release schedule
Date: Tue, 01 Apr 2003 10:09:22 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Markus Hitter wrote:

What makes you expect that an additional e.g. NSToolbar implementation whould affect the stability of GNUstep? If it whould show effects other than the expected ones, you just bring hidden bugs to the light of the day, right?

No one is suggesting that adding NSToolbar, by itself, is going to make GNUstep unstable. The problem is that GNUstep is unstable now, and spending the time to track Cocoa will take time away from fixing that instability.

One of the things I'm concerned about is the uncertain wording of the goals for GNUstep. A solid mission statement would keep everyone coding in the same direction, and supporting a moving target is going to add more and more complexity to something that needs to be solidified, and maybe even simplified, and soon.

After all, if you want to stay with OPENSTEP exclusively, GNUstep will come to a standstill in a not too far future.

If you reread some of the emails, no one's saying that GNUstep should stay *exclusively* with OPENSTEP. However, the general feeling (amongst anti-Cocoa-trackers, at least ;)) is that having a solid, non-changing base as a reference to work from is extremely important. OPENSTEP provides that solid base. One could code an environment straight from the OpenStep Specification, and the API would NOT change, which makes life a whole lot easier for developers. Yet, no one is saying that GNUstep should be only an OpenStep/OPENSTEP clone, either. The suggestion is that GNUstep should start with a solid OpenStep/OPENSTEP implementation, and possibly add technically superior and relevent code from either Cocoa, or of the project's own design.


Tim Harrison

reply via email to

[Prev in Thread] Current Thread [Next in Thread]