On Tue, Jul 8, 2014 at 8:38 AM, Benoit Chesneau <[email protected]> wrote: > On Tue, Jul 8, 2014 at 6:13 AM, Alexander Shorin <[email protected]> wrote: >> On Tue, Jul 8, 2014 at 8:03 AM, Benoit Chesneau <[email protected]> wrote: >>> On Mon, Jul 7, 2014 at 9:11 PM, Robert Samuel Newson <[email protected]> >>> wrote: >>>> Hi All, >>>> >>>> The merge of bigcouch has reached a stage now where I think it’s time to >>>> merge to master. I’m therefore asking folks if there are any blockers >>>> preventing me from proceeding, which involves you each taking a look at >>>> 1843-feature-bigcouch (or, by not doing so, giving implicit consent). >>> >>> hrm shouldn't we have the new features and changes documented before the >>> merge? >> >> We can make this on master branch too, not a blocker requirement and >> it could takes 2-3 weeks to review and update whole our docs (API is >> just a part of them). >> > The user doc can probably wait, but all changes should be documented > imo. To help the review.
It's still the question about the weeks. Current API section took around one month for me without rushing things and still on implementing yet another couchdb client I found it buggy and wrong in certain places. I'm working on the sphinx ext to let us test API docs and find out which examples are broken and which cases aren't covered. Deadline is on the next week. But agree that docs might help with review (especially in case to see what exactly need to be reviewed). However I think the best strategy for now is take your favorite couchdb client and try to work with against BigCouch branch - you should notice API endpoints which are gone and which well known are broken. This would cover compatibility case. As for new features source code is the best friend for now. -- ,,,^..^,,,
