subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: Hide experimental APIs to unblock 1.11 release
Date Thu, 20 Sep 2018 19:54:26 GMT
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

View raw message