Stefan Fuhrmann wrote:
> * svn_wc__conflict_description2_dup
> Simply move this private API to svn_wc_private.h.
> Ideally, people would never have called it but clients
> might not have had a choice. So, we must keep it in
> the ABI but remove it from the public API.
On reading this, at first I found myself wanting to argue that we have
no duty to maintain private APIs and that we should simply delete it.
Then I swung towards arguing that it's more important to avoid
needlessly breaking apps when users upgrade the libraries (even though
it's the app's author's fault), and so we should to keep it (at least
in the ABI).
But these arguments are not the right way to make this decision. We
should follow our policy.
If we make an individual decision in each case, then it is likely that
upgrading our libraries will remove some proportion of the old private
symbols and so break some of the apps that used any private symbols. A
decision to keep one particular symbol won't help any app that also
used another that we didn't decide to keep.
So what is our policy? (We should write it down if we haven't already done so.)
I can't find anything about it in our 'Deprecation' section
<http://subversion.apache.org/docs/community-guide/releasing.html#deprecation>.
If we decide to keep the code for the ABI, then the declaration may
(I'm not sure) need to be present in svn_wc_private.h (rather than
just local to the definition) in order to satisfy the DLL export logic
of our Windows build system. I *think* that would be the only reason
to keep it there. If that is the case, then we must document the
declaration as such, otherwise one of us will come along and delete it
later, since private symbols are generally open to deletion or
modification at any time.
- Julian
Received on 2015-04-10 11:20:55 CEST