couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [DISCUSS] Removing "delayed_commits"
Date Mon, 10 Nov 2014 15:06:46 GMT

> On 10 Nov 2014, at 15:17 , Klaus Trainer <klaus_trainer@posteo.de> wrote:
> 
> Hey Jan,
> 
> 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?

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’t run into a Python 3 situation that creates a major
schism in the user community that takes a decade to heal.

Let’s not break things because we update the major version number,
instead, let’s update the major version number whenever we break
back backward compatibility.

Best
Jan
--




> 
> 
> On 10.11.2014 15:07, Jan Lehnardt wrote:
>> I’d say let’s keep em for now.
>> 
>> Best
>> Jan
>> --
>> 
>>> On 10 Nov 2014, at 12:40 , Klaus Trainer <klaus_trainer@posteo.de> wrote:
>>> 
>>> Hello everybody.
>>> 
>>> I'd like to hear your thoughts about removing the `delayed_commits`
>>> option together with the corresponding code paths.
>>> 
>>> Note that independent of this discussion (and in contrast to 1.x
>>> releases), the delayed commits feature will be disabled by default in
>>> the upcoming 2.0 release.  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.
>>> 
>>> Speaking for myself: I've never needed that feature, and I'd certainly
>>> not miss it.  I remember several times where I was in the awkward
>>> position of having to explain it.  After recommending people to not
>>> enable delayed commits in production, I'd usually get asked about the
>>> purpose of that feature.  Then I would answer something awkward like
>>> "we've implemented and enabled delayed commits by default so that
>>> CouchDB looks good in certain benchmarks".
>>> 
>>> Would you miss delayed commits?  Do you think that users would miss it,
>>> and if so, why?
>>> 
>>> Thanks,
>>> Klaus
>>> 
>> 
> 


Mime
View raw message