> On 10 Nov 2014, at 16:11 , Alexander Shorin <kxe...@gmail.com> wrote: > > On Mon, Nov 10, 2014 at 6:06 PM, Jan Lehnardt <j...@apache.org> 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. >> >> 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. > > 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’d be happy to hear more about what problems Russell had, but it’s the first time that info hits dev@ and it wasn’t brought up in this thread so far. Best Jan --
