Re: Next stable release?

[Richard Frith-Macdonald]

On 8 Jun 2008, at 13:30, David Chisnall wrote:

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

The problem is, we've been using that mechanism for years and it  
hasn't worked.  People either don't bother or forget to set the  
appropriate macros.  I know this because nobody ever complains about  
errors in the version macro conditionals in the headers ... and there  
have been a lot of them that I've found and fixed myself.

So what I want to do is have the library as OSX compatible as possible  
*by default* ... but have non OSX stuff available in the Additions  
library (built into gnustep-base by default, but with separate headers  
to include).

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

That's what the additions library is for ... with the added advantage  
that MacOS-X users can use the library (built standalone without the  
base library) on MacOS-X.

If we deprecate features, we are then free to move them to the  
additions library, make them private within base (if base uses them  
but nobody else does), or drop them completely if practically nobody  
is using them.