On Thu, Nov 13, 2008 at 9:08 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> There are two ways to make an API stable. Use it, test it, and become
> comfortable that it is right, or promise that it will be stable from now
> on and then do whatever is necessary to support it the way it is, even
> if that turns out to be poor and supporting it restricts further
> development.
>
> I don't like the idea of promising to support these, when there don't
> seem to be any significant benefits to doing so. Mark agreed.
We talked about this a bit at the summit. If we could start over, I
do not think the WC library should be public at all. We'd probably
have to expose some more things at the client level, but I do not
think we did ourselves any favors by making that part of our code a
public API. I am sure there are some consumers of this API out in the
wild, but I'd be willing to bet the number is very small.
Given that we cannot start over, then we have to maintain this API and
that also means adding new API for new features. I simply said to
Julian that I did not think there was any reason to rush out and start
making more of the API public. We know the Tree Conflict feature will
need to evolve over the next couple releases as it expands to cover
more. I just did not see any reason to declare the API as public in
1.6.
This is not about the code being stable or doing what it is supposed
to, it is about do we understand this feature enough today that we
want to create an API interface we want to support forever. I do not
think we are there yet and given that I cannot see who would ever
consume this API, I do not see a reason to make it public right now.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-13 15:19:37 CET