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.
If we have extensions that people find useful, then they should be
maintained for people who don't value OS X compatibility.
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
