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. -- ,,,^..^,,,
