I would like to see 'JSONP responses should be sent with a "application/javascript"' (https://github.com/apache/couchdb/pull/236) beside the two merges in the 2.0 release - it is a small, but breaking change and the original issue is flying around in Jira for years.
Best, Robert 2014-07-13 22:17 GMT+02:00 Robert Samuel Newson <[email protected]>: > > Since we follow semantic versioning, the only meaning behind naming our > next release 2.0 and not 1.7 is that it contains backwards incompatible > changes. > > It’s for the CouchDB community as a whole to determine what is and isn’t > in a release. Certainly merging in bigcouch and rcouch are a huge part of > the 2.0 release, but they aren’t necessarily the only things. If they > hadn’t changed the API in incompatible ways, they wouldn’t cause a major > version bump. > > With that said then, I’m interested in hearing what else, besides the two > merges, we feel we want to take on in our first major revision bump in > approximately forever? At minimum, I would like to see a change that allows > us to use versions of spidermonkey released after 1.8.5, whatever that > change might be. > > B. > > On 13 Jul 2014, at 20:31, Joan Touzet <[email protected]> wrote: > > > Improving the view server protocol is a great idea, but it is appropriate > > for a 2.0 timeframe? I would think it would make more sense in a 3.0 > > timeframe, given 2.0 is all about merging forks, not writing new features > > entirely from scratch. > > > > -Joan > > > > ----- Original Message ----- > > From: "Robert Samuel Newson" <[email protected]> > > To: [email protected] > > Sent: Sunday, July 13, 2014 8:52:40 AM > > Subject: Re: CouchDB 2.0: breaking the backward compatibility > > > > > > Adding mvcc for _security is a great idea (happily, Cloudant have done > so very recently, so I will be pulling that work over soon). > > > > A better view server protocol is also a great idea. > > > > > > On 13 Jul 2014, at 13:13, Samuel Williams < > [email protected]> wrote: > > > >> > >> On 13/07/14 23:47, Alexander Shorin wrote: > >>> Our view server is compiles functions on each view index update > >>> instead of reusing inner cache. This is because of out-dated protocol: > >>> others design function are works differently from views. While it's > >>> good to change and improve query server protocol completely, this task > >>> requires more time to be done. We should have a least plan B to do > >>> small steps in good direction. > >> As already suggested, here is my proposal for 2.0 view/query server: > >> > >> > https://docs.google.com/document/d/1JtfvCpNB9pRQyLhS5KkkEdJ-ghSCv89xnw5HDMTCsp8/edit > >> > >> I welcome people to suggest improvements/changes/ideas. > >> > >> Kind regards, > >> Samuel > > > >
