couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Fauxton compatibility with CouchDB 1.x
Date Sun, 10 Aug 2014 13:25:25 GMT
I could only counterargument you that current incompatibility is too
synthetic: Fauxton decides to know too much CouchDB details (system
roles for our case) which obliviously causes incompatibility issues.
Instead of LBYL[1] approach better follow EAFP[2] one - this also will
simplify support of possible forks, DBaaS and features mismatch due to
different configuration.

But with a lot of sadness bits, I can accept your decision. Then there
is need to make Fauxton build aware on CouchDB 2.0 presence and warn
if it going to work against 1.x version. Otherwise other people will
report of each incompatibility - probably, non of Fauxton developers
want to deal with them and explain again and again why they wouldn't
be fixed.

[1]: LBYL: Look before you leap. Aka defensive approach when you check
all the bits before make an action. What's Fauxton currently does and
what causes the issues for now.
[2]: EAFP: Easier to ask for forgiveness than permission. When you
assume that action is allowed and only exception/error signs you that
it's not. In term of CouchDB client make an request as is and make a
decision on response status code.

On Sun, Aug 10, 2014 at 4:26 PM, Robert Kowalski <> wrote:
> I would prefer to test Fauxton just against the coming 2.x
> Fauxton is always called "experimental" for 1.x and maintaining Fauxton for
> both 1.x and the coming 2.x including testing, releases and so on costs
> alot of resources, so I would prefer to drop 1.x support now and just test
> against 2.x.
> As Fauxton will get the default UI for 2.x I would like to focus on
> shipping it in a good and working state for 2.x first.
> Best,
> Robert
> 2014-08-09 22:58 GMT+02:00 Alexander Shorin <>:
>> Hi devs,
>> There was raised interesting question about Fauxton compatibility with
>> CouchDB 1.x series. Currently this compatibility is broken in form of
>> [COUCHDB-2244] issue and [#57923f457] commit. And that's only which we
>> aware for now.
>> So what is the general plan? Make Fauxton works fine with 2.0 leaving
>> 1.x support out of border (and certainly, there will no more updates
>> for experimental feature), or keep it compatible with both for a while
>> until 1.x will gone into the history? I think we should set all dots
>> above the i in this question. As a side effect this will explicitly
>> define required testing environment for Fauxton - personally, I'm
>> using and reporting issues against 1.x which may be irrelevant for
>> 2.x.
>> So what's the plan have to be? What do you think?
>> [COUCHDB-2244]:
>> [#57923f457]:
>> --
>> ,,,^..^,,,

View raw message