Sure, I'm just outlining why in don't like the original reasoning. I haven't heard any other argument why we should drop it for 2.0. :)
Best Jan -- > On 10.11.2014, at 17:42, Klaus Trainer <klaus_trai...@posteo.de> wrote: > >> On 10.11.2014 16:06, Jan Lehnardt wrote: >> >>> 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. > > Thanks for your explanation, those are good points. However, in this > case, I feel certain that people will hardly notice the removal, let > alone miss the feature. But I can only speak from my experience. > > In the end the only point where I seem to disagree is that I don't think > that the change will make the transition to 2.0 significantly harder. > >> >> 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. > > Thanks for explaining our new way of doing semantic versioning. I now > remember that it had been explained before, by different people, and > quite a few times ;) > > It feels kinda weird thinking of a new major release where the only > change is a feature being *removed*, but from a semantic versioning > perspective it is right. > >> >> 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 >
