couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Fauxton compatibility with CouchDB 1.x
Date Mon, 11 Aug 2014 08:39:05 GMT
Hi Garren,

Thanks for the offer to help with making Fauxton compatible with 1.x,
but that's would be counter productive if the baseline of Fauxton
development is to align on 2.x features and behavior and only. As far
as more incompatibilities will be introduced as more hacks (because
without them it would be hard to simulate roles-that-are-not-exists
for 1.x correctly, for instance; _all_dbs will be the next stop point
etc.) I would have to apply to keep it working for 1.x and this
certainly will slowdown overall development and makes code base
support harder. That would be only reasonable if you hadn't any plans
to drop 1.x support, but since you have them...Ok, I heard you (:

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


On Mon, Aug 11, 2014 at 11:46 AM, Garren Smith <garren@apache.org> wrote:
> I agree with Robert. I think Fauxton should be “experimental” for 1.x and we should
focus on 2.x. That being said its probably not that hard to get Fauxton working properly with
1.x. So Alex if you feel that strongly about it you are welcome to get it working with 1.x.
I can give you a couple pointers on how to get started if you want.
>
> Cheers
> Garren
>
>
> On 10 Aug 2014, at 3:25 PM, Alexander Shorin <kxepal@gmail.com> wrote:
>
>> 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 <rok@kowalski.gd> 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 <kxepal@gmail.com>:
>>>
>>>> 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]: https://issues.apache.org/jira/browse/COUCHDB-2244
>>>> [#57923f457]: https://github.com/apache/couchdb-fauxton/commit/57923f457
>>>>
>>>> --
>>>> ,,,^..^,,,
>>>>
>

Mime
View raw message