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 11:57:59 GMT
On Mon, Jul 22, 2013 at 3:37 PM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> On Mon, Jul 22, 2013 at 12:21 PM, Jan Lehnardt <jan@apache.org> wrote:
>>> 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.
>
> I think the docs part is definitely the most important. We should find
> some way to do Sphinx roles for this so we can encode it in a somewhat
> reliable way.

That's not a problem:

:status: stable

+ some styles around (or even own extension to provide custom directives)

The problems are:
- Big merges: we'll have a lot of "unstable" or not "tested
extensively in production" API for quite large period of time.
- Psyhology: marking something as experimental raises interest from
hackers and advanced users, regular users will never use these things.
Unstable badge is not so attractive for hackers, but still regular
users will try to avoid such API. As the result, API and features will
not receive good feedback from wide people and this will create
deadloop: need more feedback to mark feature as stable, need stable
badge to use feature intensively and give a lot of feedback. Time is a
good tester, but it doesn't writes bug reports. Stable looks good, but
ah, still not yet ready for production, let's wait for a while. And so
on.


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

Mime
View raw message