Hi all, Several times in recent months we’ve had discussions on this list about behavior changes in CouchDB 4.0 that boil down to tradeoffs between
a) maintaining compatibility with current CouchDB APIs, and b) capitalizing on the transactional semantics of FoundationDB An example would be the support for large result sets in a view response: do we stitch together multiple transactions to support very large responses, or provide new pagination APIs and guarantee that each response is generated from a single isolated snapshot? I’d like to suggest that we “have our cake and eat it, too” by introducing versioned APIs as previously suggested by Ilya[1]. We’d have a V3 API that strives to maximize compatibility with CouchDB 3.x, and a V4 API that still looks and feels like CouchDB, but introduces breaking changes where necessary to provide well-defined transactional semantics. I think this explicit approach to API evolution could make life easier for client library maintainers, and also free us up to improve the API without needing to be quite as careful about in-place backwards compatibility. [1]: https://lists.apache.org/thread.html/rcc742c0fdca0363bb338b54526045720868597ea35ee6842aef174e0%40%3Cdev.couchdb.apache.org%3E What do you think? Cheers, Adam
