Given that 4.0 is not one, but two major versions away from 2.X, what is the reason to just not deprecate this behavior and remove it entirely?
4.0 probably wouldn’t be out for another year at least and deprecating information can be included in 3.0 once out. I see no reason to include things in a new major release that don’t actually do anything personally. Tabeth > On Oct 29, 2019, at 6:36 PM, Arturo GARCIA-VARGAS <art...@ficuslabs.com> > wrote: > > I got a bit curious about this one. I see that batch=ok simply spawns the > update. I am on couchdb master, and I can see the commit regarding > _ensure_full_commit -it's now a no-op: > > commit dc054e7ddcc3ea059e1f86a7039cf86912ab1052 > Author: Nick Vatamaniuc <vatam...@apache.org> > Date: Thu Sep 26 01:33:01 2019 -0400 > ... 8< ... 8< ... 8< ... > `/_ensure_full_commit` HTTP API was left as is since replicator from older > versions of CouchDB would call that, it just returns the start time as if > ensure_commit function was called. > > Issue: https://github.com/apache/couchdb/issues/2165 > > If there is no real /_ensure_full_commit anymore, then we cannot spawn > anymore. Therefore, I personally think batch=ok should be removed altogether. > >> On 29/10/2019 19:10, Robert Newson wrote: >> I am fine with returning 202 even though we blocked to complete the request. >> B. > Seems like a good compromise until total deprecation, as spawning is not an > option. > > Saludos! > > Arturo
