Julian Foad wrote on Fri, Apr 10, 2015 at 10:20:02 +0100:
> 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.
Another option: keep it in svn_wc.h protected by an '#ifdef
SVN_EXPOSE_LEGACY_DUNDER_SYMBOLS', which won't be defined by default.
API consumers that used dunder symbols from the public headers in the
past will have to add that define to their build flags. This way, new
code doesn't see the dunder symbols, but legacy code isn't needlessly
broken, either.
Daniel
("dunder" is short for "double underscore".)
Received on 2015-04-10 18:54:21 CEST