Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
Subject: Re: [DISCUSS] Removing "delayed_commits"
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: 
 <CAHdjip+JRrne1ZhEgotKygitLdEeOmR4n3u5F1ms6+gfw0K6NA@mail.gmail.com>
Date: Mon, 10 Nov 2014 16:40:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF94CB52-1EEA-48F2-A4AB-6AF89234EACC@apache.org>
References: <5460A43F.8000807@posteo.de>
 <8FCB5B70-DD0F-4BAE-B90C-1F4917D64900@apache.org>
 <5460C8F0.5010704@posteo.de>
 <266BA271-1BDB-420C-9078-6DF208C25CE2@apache.org>
 <CAHdjip+JRrne1ZhEgotKygitLdEeOmR4n3u5F1ms6+gfw0K6NA@mail.gmail.com>
To: dev@couchdb.apache.org


> On 10 Nov 2014, at 16:11 , Alexander Shorin <kxepal@gmail.com> wrote:
>=20
> On Mon, Nov 10, 2014 at 6:06 PM, Jan Lehnardt <jan@apache.org> wrote:
>>> On 10 Nov 2014, at 15:17 , Klaus Trainer <klaus_trainer@posteo.de> =
wrote:
>>>=20
>>> Hey Jan,
>>>=20
>>> you didn't provide an argument, so I can only guess: Do you think =
that
>>> we shouldn't tackle that right now, as it would potentially delay =
the
>>> 2.0 release?
>>=20
>> One of my goals for CouchDB 2.0 is that people upgrading form 1.0 and
>> especially people who continue use CouchDB in a single-node scenario
>> have an easy time. Just breaking more things because we happen to be
>> bumping a version number is not a good motivation. Especially in our
>> new world of avoiding attaching marketing connotation to major =
release
>> versions (except 2.0 :), we can release CouchDB 3.0 and 4.0 shortly
>> after 2.0 if it means we break BC in a single way. If we keep BC =
breaks
>> to a minimum and make every transition up a major version as easy as
>> possible, we don=E2=80=99t run into a Python 3 situation that creates =
a major
>> schism in the user community that takes a decade to heal.
>>=20
>> Let=E2=80=99s not break things because we update the major version =
number,
>> instead, let=E2=80=99s update the major version number whenever we =
break
>> back backward compatibility.
>=20
> Suddenly, active delayed_commits is what is breaking CouchDB 2.0 - ask
> Russell how long he fight with database migrations from old 1.x to 2.0
> until he found delayed_commits turned on.  Also, I don't think that
> this change is breaking something expect benchmarks speed.

I was referring to the original email that said:

> I'd like to propose that we now (as we're already breaking API
> compatibility with the new major release) go the full way and
> remove that feature entirely.


I generally disagree with that reasoning as outlined above.

I=E2=80=99d be happy to hear more about what problems Russell had, but =
it=E2=80=99s
the first time that info hits dev@ and it wasn=E2=80=99t brought up in =
this
thread so far.

Best
Jan
--