Re: Next stable release?

[Richard Frith-Macdonald]

On 10 Jun 2008, at 18:47, David Ayers wrote:

> Richard Frith-Macdonald schrieb:
> > On 10 Jun 2008, at 15:28, David Ayers wrote:
> >
> > > Richard Frith-Macdonald schrieb:
> > >
> > > > Where we have methods which are GNUstep specific, they ought to  
> > > > be in
> > > > 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.
> >
> > Perhaps I'm misunderstanding you ... but if you do that, then all
> > existing source code would fail to compile because declarations would
> > not be visible in the headers they are including now, but they  
> > wouldnt
> > be including the new header they need.
>
> I thought that this commit ...
> http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Headers/Foundation/NSString.h?rev=26621&view=diff&r1=26621&r2=26620&p1=libs/base/trunk/Headers/Foundation/NSString.h&p2=/libs/base/trunk/Headers/Foundation/NSString.h
> [http://tinyurl.com/3j3ysu]
> ... already breaks existing source code.

Thanks ... I made a typo and used the wrong macro name (fixed)
With GS_API_VERSION(GS_API_NONE, 011700) it should change the validity  
of the methods in the GNUstep category from being always valid (no end  
version), to being valid up to release 1.17.0

Since the current stable/unstable branches are 1.14.x and 1.15.x I  
expect the next stable release to be 1.16.0 and the next unstable one  
to be 1.17.0
This should mean that in the next stable release the methods are still  
valid (usable), but autogsdoc marks them as deprecated, so people  
shoudl see that if they look at the header files or the  
documentation.  No existing code should break.

> But without providing an
> alternative header to include.  But in fact it seems that many of  
> those
> declarations already exist in GSCategories.h.  Sorry I should have
> checked earlier.  [Yet there are some declarations that are not  
> there...
> not sure what should happen to them (maybe this is only true for
> -immutableProxy]
>
> So what I'm trying to say, is that we should insure that all those
> methods are declared in GSCategories.h without the version macros.   
> And
> maybe add a comment in the Foundation files to indicate where these
> declarations have moved to.

I don't have time to decide where everything moves to in the next  
day ... I doubt that I even have time to be sure  I find all the  
methods which are not in MacOS-X

> > I want current code to continue to compile and work with no  
> > changes, but
> > to warn developers that things are going to change before the next
> > stable release.
>
> Well if someone is using version macros now, they'll notice that the
> declarations are hidden.  If not, I suppose they can't get warned with
> the current infrastructure.  They'll notice once the declarations are
> removed from the file which should probably still contain a general
> comment about where declarations have been moved to.

autogsdoc parses the version macros to mark methods as deprecated when  
it knows there is a removal date in the macro.
I think we could put more detailed documentation in the next bugfix  
release.