gnustep-dev
[Top][All Lists]
Advanced

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

Re: Next stable release?


From: Richard Frith-Macdonald
Subject: Re: Next stable release?
Date: Tue, 10 Jun 2008 14:53:57 +0100


On 10 Jun 2008, at 14:28, David Ayers wrote:

Richard Frith-Macdonald schrieb:

I believe that marking features that will be merely moved to - additions
as deprecated is misleading.  To me deprecation means prepare for
removal... i.e. adapt all your code. If it just means "we are thinking
about this" then deprecation means "follow the commits minutely to see
what actually happens".

So please...
a) reconsider deprecating anything that you are not sure that we need to
remove and
b) only remove things that pose a real maintenance burden.

It really isn't fun updating a hoard of custom applications just because Apple has the resources to churn the API and Runtime as it is currently
doing.

I understand where you are coming from, but I don't have a good solution. We are rushed to do a new release this week, so we don't have a lot of time to come up with a solution.

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.

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.

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).

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.




reply via email to

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