On 16.09.2018 22:24, Julian Foad wrote: > In this thread we have a lot of suggestions and disagreements. I started > looking for existing practices that we could copy, and here is the first > thing I found. The top three hits in a DuckDuckGo search for "experimental > APIs" [1] have in common the use of a run-time guard that prevents ordinary > stable client software from accidentally using them by requiring an explicit > acknowledgement action. > > Chrome: you must enable Experimental Extension APIs in your browser, and "the > Chrome Web Store doesn't allow you to upload items that use experimental > APIs". > > Windows: "By default, these APIs are disabled at runtime and calling them > will result in a runtime exception." > > OpenStack: "clients must include a specific HTTP header, > X-OpenStack-Manila-API-Experimental". > > That's not something we've considered before. We could think of ways to > implement such a thing, but, before we go there, even just having the > possibility in mind may help us think more clearly about what we wish to > achieve.
The proposal to put experimental APIs (and command-line features) into a separate namespace is a variant of this off-by-default approach. Since Subversion is a set of libraries, we can't exclude the experimental bits from the ABI (or rather, we can, but doing so would defeat the purpose of having experimental bits in the first place). Instead, we force downstream developers and users to consciously choose to use experimental features, with all that the choice implies. A corollary of the above is that we should never have aliases for experimental bits in another namespace: for example, if there is an 'svn x-shelve' command it should not have an 'svn shelve' alias, since that could lead users to believe that the feature is no longer experimental. Consequently, releasing experimental features to the stable set implies removing associated functions, types, commands, etc. from the experimental namespace — and yes, this *will* create ABI incompatibilities. If we decide that we cannot allow that and that ABI compatibility is more important even for experimental stuff, we can keep dummy functions that return APR_ENOTIMPL (we don't have to invent a new error code). As to what should be marked experimental, I maintain that my definition elsewhere in this thread matches our original reason for introducing the concept in the first place: to allow for developing experimental features across multiple minor releases in a way that lets users test them and give us feedback, yet allows us to avoid the burden of maintaining permanent API/ABI compatibility for defunct functionality. -- Brane
