couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filippo Fadda <>
Subject Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Date Mon, 22 Jul 2013 11:47:49 GMT
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.


On Jul 22, 2013, at 12:21 PM, Jan Lehnardt wrote:

> On Jul 22, 2013, at 12:13 , Alexander Shorin <> wrote:
>> On Mon, Jul 22, 2013 at 1:48 PM, Jan Lehnardt <> 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
> --

View raw message