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: https://cwiki.apache.org/confluence/display/SVN/Experimental+APIs > 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
