Re: Hide experimental APIs to unblock 1.11 release

2018-10-01 Thread Daniel Shahaf
Julian Foad wrote on Mon, 01 Oct 2018 15:43 +0100: > We should stop making a distinction between "private" and "experimental" > and just say that everything not declared as public is in the same > bucket, available for interested developers to look at and use -- that's > the nature of open sourc

Re: Hide experimental APIs to unblock 1.11 release

2018-10-01 Thread Julian Foad
Branko Čibej wrote: > Stefan Küng wrote: > > How about moving the experimental headers into a separate subfolder? > > Right now, there's: > > subversion/include > > subversion/include/private > > and the experimental headers are now in subversion/include/private. > > No they are not. The shelving

Re: Hide experimental APIs to unblock 1.11 release

2018-09-30 Thread Branko Čibej
On 30.09.2018 20:51, Stefan Küng wrote: > > > On Thu, Sep 20, 2018 at 10:13 PM Julian Foad > wrote: > > Julian Foad wrote: > > Stefan Kueng wrote: > > > but then that would mean I wouldn't get any compiler > > > error if I actually use a private and no

Re: Hide experimental APIs to unblock 1.11 release

2018-09-30 Thread Stefan Küng
On Thu, Sep 20, 2018 at 10:13 PM Julian Foad wrote: > Julian Foad wrote: > > Stefan Kueng wrote: > > > 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 -- [...] > > there's no real pract

Re: Hide experimental APIs to unblock 1.11 release

2018-09-21 Thread Julian Foad
One important thing I didn't make clear: I propose these APIs go in "public" headers like svn_client.h, not in the "private" header files that are by default omitted from installation. Stefan, does this make a difference to you? Do you still need to change TSVN build scripts at all for that cas

Re: Hide experimental APIs to unblock 1.11 release

2018-09-20 Thread Julian Foad
Julian Foad wrote: > Stefan Kueng wrote: > > 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 -- [...] > there's no real practical difference between "private" and > "experimental". See my no

Re: Hide experimental APIs to unblock 1.11 release

2018-09-20 Thread Julian Foad
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 a

Re: Hide experimental APIs to unblock 1.11 release

2018-09-20 Thread Stefan Kueng
On 9/20/2018 5:17 PM, Julian Foad wrote: A fresh perspective on the experimental-APIs issue just came to me: this should not hold up the 1.11 release. We were falling into the old trap of thrashing about debating how to do it, assuming we needed some solution for 1.11, but we don't. One of