Re: Next stable release?

[David Ayers]

Richard Frith-Macdonald schrieb:
> 
> 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.

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.

Cheers.
David