Experimental in PHP is used for extensions that are not bundled with PHP. Instead deprecated is used to inform the user that a function shouldn't be used anymore. In the same way CouchDB could inform that an API is deprecated or experimental.
1) X-Couch-Deprecated 2) X-Couch-Experimental Stable makes no sense at all, and unstable too, because an unstable feature should not be included in an official release. My two cents. -Filippo On Jul 22, 2013, at 12:21 PM, Jan Lehnardt wrote: > > On Jul 22, 2013, at 12:13 , Alexander Shorin <[email protected]> wrote: > >> On Mon, Jul 22, 2013 at 1:48 PM, Jan Lehnardt <[email protected]> wrote: >>> We have talked about deprecating features using HTTP headers like >>> `X-Couch-Deprecated: true` to denote a deprecation to be included in >>> releases that happen before the actual removal of a feature. We could >>> make that `X-Couch-API-Stability: [0-5]` instead, if we adopt the scale >>> above (and maybe only optionally show anything >0 to save some bytes >>> in the general case). And whatever powers that information could be >>> used to feed into the capabilities we have talked about for the welcome >>> message on `/`. >> >> X-Couch-API-Stability idea is too complex. Better to have only >> `X-Couch-Deprecated: true`. Experimental features should be enabled in >> configs so user takes responsibility for any behavior it provides. > > Fair point, happy to have the 1-5 scale in docs only, if we want to > go that route. > >> Also, this information is useless in caps. Caps notifies what server >> able to do, not how good he can. > > Well, if we have comprehensive encoded info on what state everything > is in, we will also know what we have, which could be used to form > the capabilities info. > > Best > Jan > -- > > >
