Richard Frith-Macdonald schrieb: > > On 13 Oct 2006, at 07:25, David Ayers wrote: > >> Richard Frith-Macdonald schrieb: >> >>> >>> As part of the public API, any removal/renaming will go through a >>> deprecation process ... I have tried to do a two release cycle in the >>> past (ie if it's marked as deprecated in release N, then it must still >>> be present in N+1 but we can remove it so that it is not in release >>> N+2). >>> I'd like to make that standing policy for public API removal (and I'd >>> like to get to a stage where private APIs really are private ... not >>> exposed at all beyond the technical minimum of a few external symbols >>> found in the binaries).
I'm a bit weary of the "technical minimum" approach since it seems there are at least some of us who started to rely on the documented API (without necessarily consulting the headers), but I'll stick to the sidelines until I have something more concrete. (I hope you're not considering removing md5Digest or hexadecimalRepresentation.) >> Changing names could break >> plists (such as EOModels) but that's probably not that bad as most would >> be using the common encodings which won't change. > > > Well, if we change the names of the GNUstep specific enumeration > constants, that doesn't mean that gdl2 has to change the strings it > uses in the plists to match ... it could just leave them as the are, or > change to using string matching the new enumeration names. but continue > to recognize the old ones for backward compatibility. OK, I've updated GDL2 to use the enumeration names. [snip] > > However, I don't want to change anything here until/unless we are > confident about doing the right thing. Indeed! So let me take a little more time to express myself more clearly. When I say "name space" I actually meant a reserved range. But in fact that would mean we would already have to change the codes to achieve that, which should be avoided. One concern is of course that we enumerate in range that Apple will use for different encodings. Another concern is that we may introduce encodings that Apple may introduce in the future with differing values, breaking compatibility in certain scenarios. So what I'm trying to say is that these new encodings shouldn't be handled as GNUstep specific "extensions" /if/ we can avoid it, by requesting Apple's Cocoa developers to reserve the new values in their headers. Now I realize that they may very well not care. It just seems that we could simply ask. Cheers, David _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
