I was travelling, so missed this thread originally. My[1] organization is currently not using CouchDB 2.0 in production due to a series of regressions in all 2.x releases that have meant that 1.6.1 was the most stable for us. All of the currently-known issues are fixed on master, and we're currently evaluating a nightly build to verify. It would be really nice if there was a 2.2 release so that we could get those fixes in the form of a formal build (note that we sponsored some of the work on those fixes, hoping that a release would get turned around relatively quickly afterwards).
A regular release cadence would be really nice. Cheers, Eli [1] - I should note that I've quit that company, so I'm no longer formally associated. On Fri, Jul 6, 2018 at 11:04 AM Joan Touzet <[email protected]> wrote: > I agree that this semantic change is an unfortunate problem in the 1.x to > 2.x upgrade path and needs to be addressed. > > It is irresponsible to tell users that a valid workaround is to use an > insecure, untested, not-clustered and not-fully-functional port as the > primary access to CouchDB. The consequences are worse than the workaround. > > -Joan > > ----- Original Message ----- > > > From: "Igor Ievsiukov" <[email protected]> > > To: [email protected] > > Cc: [email protected] > > Sent: Friday, July 6, 2018 12:15:26 PM > > Subject: Re: Call for "Must-fix" issues > > > Hi Joan, > > > Thank you for additional explanations. > > > I myself know this rule very well, but imagine a scenario of a > > sysadmin in some company, not aware of this nuance, upgrading > > couchdb1x => 2x on their internal app that still uses the old repl > > doc seantics – the side-effect might not be visible at first, but > > the consequences will be very nasty and a very angry user in the > > end. >
