Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A3D15BFF-9394-4539-9E4A-E5C4514BEA72@apache.org>
References: <32571631.349.1405279887656.JavaMail.Joan@RITA>
 <A3D15BFF-9394-4539-9E4A-E5C4514BEA72@apache.org>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Sun, 13 Jul 2014 15:23:19 -0500
Message-ID: 
 <CAJ_m3YCg6z5VaeP9GQ6tzu9MyaC2jSLiakijXh4DH8xa9_eSYw@mail.gmail.com>
Subject: Re: CouchDB 2.0: breaking the backward compatibility
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Changing the default respones for conflicts to include all versions
(or no version).

Fix the list API (inside couchjs) so that its a pure callback like
everything else. Not sure if we should necessarily completely revamp
the whole query server protocol for 2.0. Given that its not user
facing I'm less inclined to think it needs to be in a major release,
ie we could add a new protocol in a minor release after 2.0.

We should rename _rev to _mvcc (or _token or _lock or anything not
_rev) finally.

Removing all metadata from document bodies has been an oft requested change=
.

Seems like there was a list of these things floating around a long time ago=
.

On Sun, Jul 13, 2014 at 3:17 PM, Robert Samuel Newson
<rnewson@apache.org> wrote:
>
> Since we follow semantic versioning, the only meaning behind naming our n=
ext release 2.0 and not 1.7 is that it contains backwards incompatible chan=
ges.
>
> It=E2=80=99s for the CouchDB community as a whole to determine what is an=
d isn=E2=80=99t in a release. Certainly merging in bigcouch and rcouch are =
a huge part of the 2.0 release, but they aren=E2=80=99t necessarily the onl=
y things. If they hadn=E2=80=99t changed the API in incompatible ways, they=
 wouldn=E2=80=99t cause a major version bump.
>
> With that said then, I=E2=80=99m interested in hearing what else, besides=
 the two merges, we feel we want to take on in our first major revision bum=
p in approximately forever? At minimum, I would like to see a change that a=
llows us to use versions of spidermonkey released after 1.8.5, whatever tha=
t change might be.
>
> B.
>
> On 13 Jul 2014, at 20:31, Joan Touzet <wohali@apache.org> wrote:
>
>> Improving the view server protocol is a great idea, but it is appropriat=
e
>> for a 2.0 timeframe? I would think it would make more sense in a 3.0
>> timeframe, given 2.0 is all about merging forks, not writing new feature=
s
>> entirely from scratch.
>>
>> -Joan
>>
>> ----- Original Message -----
>> From: "Robert Samuel Newson" <rnewson@apache.org>
>> To: dev@couchdb.apache.org
>> Sent: Sunday, July 13, 2014 8:52:40 AM
>> Subject: Re: CouchDB 2.0: breaking the backward compatibility
>>
>>
>> Adding mvcc for _security is a great idea (happily, Cloudant have done s=
o very recently, so I will be pulling that work over soon).
>>
>> A better view server protocol is also a great idea.
>>
>>
>> On 13 Jul 2014, at 13:13, Samuel Williams <space.ship.traveller@gmail.co=
m> wrote:
>>
>>>
>>> On 13/07/14 23:47, Alexander Shorin wrote:
>>>> Our view server is compiles functions on each view index update
>>>> instead of reusing inner cache. This is because of out-dated protocol:
>>>> others design function are works differently from views. While it's
>>>> good to change and improve query server protocol completely, this task
>>>> requires more time to be done. We should have a least plan B to do
>>>> small steps in good direction.
>>> As already suggested, here is my proposal for 2.0 view/query server:
>>>
>>> https://docs.google.com/document/d/1JtfvCpNB9pRQyLhS5KkkEdJ-ghSCv89xnw5=
HDMTCsp8/edit
>>>
>>> I welcome people to suggest improvements/changes/ideas.
>>>
>>> Kind regards,
>>> Samuel
>>
>