Re: Next stable release?

[Richard Frith-Macdonald]

On 8 Jun 2008, at 12:08, David Ayers wrote:

> Richard Frith-Macdonald schrieb:
>
> > 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 would like to voice my opinion that I agree that being *highly*  
> Cocoa
> compatible /by default/ is a good idea with respect to making it  
> easier
> to write portable apps.  I'm also for moving the GNUstep additions to
> -baseadd.  I'm even for renaming any extensions in the NS namespace to
> GS.  I'm not convinced that deprecating all non Cocoa features is a
> desirable goal in itself.
>
> Yet we really need to make sure that we do not introduce last minute
> changes which affect applications in non-obvious ways.  I think such
> structural changes are more fit for the beginning of a release cycle.
>
> I understand the contention wrt the intended longevity of a stable
> release so I don't want the to interpreted as a veto... it's just  
> that I
> think we really need to think about the pros and cons wrt changing the
> public API (and possibly behavior) at this stage.

I have no desire to remove anything from the public API at this  
stage ... what I want to do is mark anything we might later want to  
remove (or move to another location) as deprecated, so that the  
developers using the release will know that their code should not  
depend on these features.  We need to give developers as much warning  
as possible ... which means that in a new stable release, we really  
*must* deprecate anything that we might be removing before the  
following stable release.  I'd rather deprecate things that we might  
later decide we want to retain, than leave undeprecated something we  
than want to remove.

I suppose that, in addition to marking GNUstep'isms as deprecated, we  
should also deprecate anything that Apple have deprecated.