> I think we are agreed that we want to categorise a method/class by > the version where it was introduced, and the version where it was > removed (NeXT/Apple have removed some things from their APIs)
This sounds like a good plan. Just to be clear, deprecation does NOT count as removal, right? > I would say the headers should be rearranged so that methods > appear in order of the version in which they first appeared, and > alphabetically within a version. That way, adding/findng methods > for a particular version range is trivial. Currently most of the headers are not alphabetized, but have methods organized by functional area. E.g, in NSDate: // Adding and getting intervals - (id) addTimeInterval: (NSTimeInterval)seconds; - (NSTimeInterval) timeIntervalSince1970; - (NSTimeInterval) timeIntervalSinceDate: (NSDate*)otherDate; ... // Comparing dates - (NSComparisonResult) compare: (NSDate*)otherDate; - (NSDate*) earlierDate: (NSDate*)otherDate; I'm not wedded to this, but it's been around a long time and people are used to it. Rather than changing it everywhere, how about just alphabetizing / sorting the additions and changes? > #else if OSVERSION(4.2, 10.3) > // Methods not in OpenStep, but present in OPENSTEP 4.2, then removed in How important is this tracking of OpenStep spec vs. OpenStep 4.2 (and 4.1, etc.)? Do we even have online reference documentation for this? It seems like we have just been marking "OpenStep" in the API so far without distinguishing versions and no complaints. Also, I'm worried that "OSVERSION" will be confusing, particularly when looking at code sitting on an Apple system. How about STEP_VERSION, API_VERSION, OS_API_VERSION, STEP_RELEASE, or ... ? _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
