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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev