Re: Release schedule

[Alexander Malmberg]

Adam Fedor wrote:
> Here's another try after reading more comments:
>
> <p>GNUstep's goal is to create a stable development environment based
> on the
> OpenStep standard developed by NeXT Computer Inc. (now Apple Computer
> Inc.) and the OPENSTEP implementation of this standard.

As a goal for all of GNUstep, this is good. However, I think it would be
good to say that the goal for core/ is to be the implementation of
OpenStep/OPENSTEP, as opposed to the rest (dev-apps/, dev-libs/, ...),
which is part of the surrounding environment. After all, some of the
other points only apply meaningfully to it.

[snip]
> <p>While our main goal is to have a stable system, we do not wish to
> stagnate. A stable system is achieved by coding to a fixed target. This
> fixed target is the OpenStep standard and OPENSTEP implementation.
> However,
> we will consider changes and additions to this API under the following
> circumstances.</p>
> 
> <ul>
> <li>We will add Cocoa methods and classes when they are sound and
> appropriate for the scope of GNUstep.</li>
> <li>We won't remove things that have been removed by Apple.</li>
> <li>Where there is a real problem with a change,
> we find a technically superior work-around. In rare cases, this might
> involve a change in the original OpenStep API</li>
> </ul>

This is reasonable, but as others have pointed out, we probably want the
flexibility to add our own additions (and, in some cases, changes).
(Actually, we already have a fair amount of them.) This should probably
be rephrased to be more general, maybe something like:

""
<ul>
<li>We will add methods and classes, either from Cocoa or our own
GNUstep specific additions, when they are sound and
appropriate for the scope of GNUstep.</li>
<li>We won't remove things, even if they have been removed by
Apple.</li>
<li>Where there is a real problem with a change,
we find a technically superior work-around. In rare cases, this might
involve a change in the original OpenStep API</li>
</ul>
""

We do have to be strict about the "sound and appropriate for the scope",
though. We definitely do not want creeping featurism.

> <p>Note that it is not the responsibility of the main developers to
> achieve or maintain Cocoa compatibility! We will accept patches and bug
> reports that detail Cocoa additions and/or changes and we will do our
> best to integrate these changes as long as they do not conflict with the
> previously stated rules.</p>

- Alexander Malmberg