couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Date Mon, 22 Jul 2013 10:21:34 GMT

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.


View raw message