Re: Next stable release?

[David Ayers]

Richard Frith-Macdonald schrieb:

> Where we have methods which are GNUstep specific, they ought to be in
> the additions library ... so assuming we get round to moving them,
> anyone using them will need to change their software to include the
> appropriate headers.  A small change, but still one they need to be
> aware of.

Yet, a very different change.

> I agree that a change like this is hardly as radical as 'prepare for
> removal', but we still need to let developers know somehow, and we don't
> have a mechanism for telling them to "follow the commits minutely to see
> what actually happens".  In fact, I guess they would ignore that anyway.

I think the current approach may very well encourage ignoring
deprecation warnings.  It's not clear what the how the developer should act.

> What I was thinking of doing was marking things as deprecated (since the
> version macros let us do that, and autogsdoc will adjust the
> documentation accordingly), and putting something in the release notes
> to explain exactly what we mean by deprecated in this release (ie that a
> few things will go completely, but most will just be moved into the
> additions library and require different headers to be included).

I don't think the release notes are the optimal place... but that may be
personal taste... I would prefer the source or the headers.

> If you have a better idea of how to go about this sort of thing I'm very
> willing to listen (even time consuming alternatives if you want to
> volunteer to help out).  I just don't want inaction to perpetuate the
> situation where people complain about lack of Apple compatibility.

Well I think the correct solution would be to use the version macros to
hide the declarations in the Foundation/*h headers yet to re-declare
them unconditionally in a corresponding GNUstepAdditions/*.h header.
[I'm currently not sure whether GSCategories.h is currently includable
by applications using GNUstep proper.]

Cheers,
David