[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Remaining suggested API changes for 1.9

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Sat, 11 Apr 2015 19:08:15 +0200

On Fri, Apr 10, 2015 at 7:35 PM, Branko Čibej <brane_at_wandisco.com> wrote:

> On 10.04.2015 11:20, Julian Foad wrote:
> > 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.)
>
>
> If it's declared in a public header, then it's a public API regardless
> of how many consecutive underscores there are in the name. We can't
> remove it.
>

Alright, less work to do for me then.

I was under the impression that we had moved some
private API from the public headers to the private sub-
folder for the 1.9 release. Hence, the proposal to do
the same here.

-- Stefan^2.
Received on 2015-04-11 19:08:46 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.