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 >>>> >>> >> >
signature.asc
Description: OpenPGP digital signature
