Re: Next stable release?

[David Chisnall]

On 8 Jun 2008, at 10:30, Richard Frith-Macdonald wrote:

> For the base library, reverting the license to LGPLv2 should be  
> easy, but I'd also like the next stable release to mark all non- 
> macosx stuff as deprecated ... on the basis that this would warn  
> developers about the intention to be *highly* macosx compatible.   
> Then we could either remove deprecated features (or move them to the  
> additions library and undeprecate them) at will in the unstable  
> branch after the release.
>
> If people are happy with this approach, I will at least try to  
> search out and mark things as deprecated in the next few days, but  
> if anyone wants to help with that I'd appreciate it.

I'm not sure I see the attraction in this.  There are three cases, as  
I see it:

1) Things that were in NeXT, but are not in OS X.
2) Things that are not exposed by Cocoa and are either impossible or  
require Carbon on OS X.
3) Things that were added by GNUstep and have since had incompatible,  
but semantically equivalent, APIs added to Cocoa.

For the third case, I agree that we should be deprecating the GNUstep  
extensions and adding the Cocoa versions if they don't already exist.

For the other two, it would be better to set deprecated attributes  
with a macro that was only defined if MAC_OS_X_VERSION_MIN_REQUIRED is  
defined.  Possibly tag each method with GS_EXTENSION, OPENSTEP_4, or  
MAC_OS_10_2_EXTENSION (where 2 is an example), and have these expand  
to __attribute__((deprecated)) based on defines provided in the  
GNUmakefile.

If we have extensions that people find useful, then they should be  
maintained for people who don't value OS X compatibility.

David