Julian Foad wrote on Mon, 01 Oct 2018 15:43 +0100:
> We should stop making a distinction between "private" and "experimental"
> and just say that everything not declared as public is in the same
> bucket, available for interested developers to look at and use -- that's
> the nature of open source software.
>
> If we declare X as "private" and Y as "experimental" that's just like
> saying please don't try to use X, although we use it. It makes us
> uncomfortable. We've forgotten how it works ourselves and don't want to
> deal with anybody wanting to get involved in using the software at that
> level of integration. Don't go making us look at it again and reminding
> us how bad it is; we've got other things to do.
Er, no, that's not what it means. The distinction between "private" and
"experimental" is technical, not emotional. When we say something is
private we're saying, "It's an implementation detail". When we say
something is experimental we're saying, "We'd like to make this a public
API in a future minor release, please help us do so". I think that's a
useful distinction.
> But please do take a
> look at Y, try using it, and give us your feedback on it. It's a matter
> of attitude, not a hard distinction.
>
> Instead, I would rather we start to say "Dear developer, if you look
> into Subversion and find yourself needing functionality which is
> currently not supported by public APIs, please do figure out how it
> works using the internal APIs and then try to bring us a proposal for a
> public API that would support your needs." I think that's a healthy
> approach.
Sure. If a third party has reason to use a private API, then they
should accept the risks and should work with us to promote that API
to be public.
Cheers,
Daniel
Received on 2018-10-01 17:02:30 CEST