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

Re: Hide experimental APIs to unblock 1.11 release

From: Julian Foad <julianfoad_at_apache.org>
Date: Thu, 20 Sep 2018 20:54:26 +0100

Stefan Kueng wrote:
> On 9/20/2018 5:17 PM, Julian Foad wrote:
>> We should just pull the experimental APIs from the public API space (moving them into the private API space) and get on with the release.
> But if they're in the private space, other clients can not use them.
> Sure, I could add some workaround in the TSVN build to pull in the
> private headers,

Clients using a build from source, like yours, can use them. I'm sorry it's more work but that seems to be the best option right now.

> but then that would mean I wouldn't get any compiler
> error if I actually use a private and not just an experimental API.

That's part of the point -- in our discussion of what an "experimental API" means there is quite a strong sentiment (myself included) that there's no real practical difference between "private" and "experimental". See my notes on that topic here:

> Why not just leave it like it is for now - the docs clearly mark the
> APIs as experimental, and IMHO that's good enough (at least for now).

Because others expressed concern that if unstable functions appear in the 'public' API, these present source-code markings do not provide sufficient protection against accidental misuse and subsequent breakage. See the main thread "API review for 1.11; do we need to mark new APIs as experimental?" for the discussions.

Given the need to get 1.11 out now while we continue to work out a better way to expose the experimental APIs, does this now make sense to you as a practical interim solution?

- Julian
Received on 2018-09-20 21:54:34 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.