couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Date Mon, 22 Jul 2013 12:08:32 GMT
On Mon, Jul 22, 2013 at 3:58 PM, Filippo Fadda
<filippo.fadda@programmazione.it> wrote:
> On Jul 22, 2013, at 12:13 PM, Alexander Shorin wrote:
>> Experimental features should be enabled in
>> configs so user takes responsibility for any behavior it provides.
>
> I don't agree because when a feature is not experimental anymore you have to remove it
from the "experimental list" and that can introduce new bugs. We are talking about APIs included
by default; these APIs are there, but no one is telling you to call them. If you do, the special
header field "X-Couch-Experimental" is there to inform that you have called an experimental
API, that normally you are not gonna call. It's just a warning, that's all. IMHO.

If uncommenting config options introduces new bugs, so removing him
from experimental list was a mistake, tests are bad and this should be
fixed as soon as possible (:

I'm in doubt about X-Couch-Experimental header. If for
X-Couch-Deprecated client library __may__ raise some warning about
"hey, resource you're requested is deprecated! alarm! alarm!", what
the reaction should be for X-Couch-Experimental? There couldn't be any
warnings, because I'm explicitly calls some resource - so I'm aware
about it existence, know how it works and docs have to aware me about
experimental status. Otherwise it makes no sense.

--
,,,^..^,,,

Mime
View raw message