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.)
[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.