Hi Michael, Thanks so much for a great series of emails. With my PMC hat on:
> Is this actually worthy of a 3.0 moniker; it seems like it could be > (breaking changes and dropping 1.X compatibility)? This is part of the to-come Branding discussion, but yes, there will be a clear delineation between the current "CouchDB Classic" and the new FDB-based CouchDB, which may actually be CouchDB 4.0, or "CouchDB Next 1.0". There's a strong desire from everyone I've talked to so far to release "the best CouchDB Classic we can before we release the FDB-based CouchDB", and if more API deprecations need to occur, I wouldn't be surprised if that new release line would be CouchDB 3.0. > Some general, higher level, thoughts (that probably mimic what you > guys > have already been thinking): As to your wishlist - let's break that off to a different discussion, in the to-be-posted Current Roadmap discussion. The items in the Current Roadmap are things that the committer base + the PMC agreed to take as development priorities about 24 months ago: https://s.apache.org/couch2xroadmap I would love to see as many of these land in that 3.0 (prior to FoundationDB) timeframe as possible. Some, like replacing our dependency on mochiweb (Erlang HTTP server module), must necessarily be deferred in the interest of retaining maximum backward compatibility. Adding to that backlog is certainly possible, but we already have a pretty deep list of topics to deal with. I don't mean to sound defensive, but we (well, IBM, but I mean the general active committer community) have been adding incremental features to CouchDB for a while now - Mango, pluggable storage engines, the replicator scheduler, and just this past week partitioned databases. That's been the motivation behind moving from 2.0 -> 2.1 -> 2.2 -> 2.3 -> to-be released 2.4 for partitioned DBs. They may not be the features that you asked for, but they are the features people contributed code for ;) I agree that we need to do better at encouraging the community to propose these sorts of things, and contribute the code to them, just as IBM is graciously offering with this FDB proposal. My soon-to-be- posted RFC proposal should help improve the process by which we get these proposals out into the community, discussed, and reviewed before code starts being written. I don't want to see someone in the community write a full implementation for their new idea, then post a pull request against our code repository just to have a more experienced developer reject it on technical grounds. (We have found ourselves in this situation a few times since 2.0, sadly.) And as Robert mentions, FoundationDB at the bottom should actually improve our ability to do exciting things by abstracting away some of the problems. That said, we can't ignore the FoundationDB code base itself - one more of the to-come 8 posts is targeted at this very topic. Thanks for the posts - keep them coming! -Joan
