> On 10 Nov 2014, at 15:17 , Klaus Trainer <klaus_trai...@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_trai...@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 >>> >> >
